Your database is only as good as its data entry

A company of eight people runs on a shared spreadsheet, a WhatsApp group and a folder of PDFs. Sales knows what was sold. Finance knows what was collected. The owner knows both, from memory, most of the time. Nobody is wrong, but there is no single place where the answer lives, so every question becomes a small investigation.

That works until it does not: a second salesperson, a second currency, a customer who pays in three parts, an accountant who asks for last quarter by product. Each of these is a small event. Together they are the reason the spreadsheet now has six tabs and two copies.

Most teams look for the fix in reporting: a dashboard, a BI tool, an export. It rarely helps, because a report can only be as good as the record underneath it. If the same customer exists under three spellings, the dashboard shows three customers. If a payment was typed in the wrong column, the margin is wrong in every chart, forever.

A database is not a fancier spreadsheet. It is a set of decisions about what exists in the business (customers, products, orders, payments, accounts) and how those things relate. Once those decisions are written down and enforced, every row that enters has to fit. That constraint is the whole value: it makes the data trustworthy without anyone checking it by hand.

• Every future tool gets cheaper. Analytics, dashboards, an AI agent, an integration with your accountant: each one reads the same record instead of needing its own cleanup project first.
• History becomes an asset. Ten weeks of prices, two years of collections and days of stock are only useful if they were recorded the same way every week. You cannot buy that history later.
• People become replaceable in the good sense. When the process lives in the data and not in someone's head, a new hire is productive in days and a vacation is not a crisis.
• Due diligence stops being a scramble. A bank, an investor or a buyer asks for the numbers by month, by product, by customer. With a record, that is a query. Without one, it is three weeks.
• AI works. Language models are very good at reading a governed record and very bad at guessing what a spreadsheet meant. The companies that get value from AI in 2026 are, almost without exception, the ones that sorted their data first.

Here is the uncomfortable part: the database does not fill itself, and the reason companies drift back to spreadsheets is that the database made data entry slower. Ten fields, three dropdowns and a required code nobody remembers, and the team goes back to WhatsApp.

So the design question is not "which database" but "how does a row get in with the least friction and the most checking". Our answer is AI data entry: the source stays whatever it is today (a PDF price list, a supplier's spreadsheet, a voice note that says "sold five kilos to Café Norte, paid in pesos"), a model reads it and proposes the rows, a person sees a preview and confirms, and only then does the code write to the database. The person types almost nothing and the record stays clean.

Two rules make this safe. The model never writes directly; it proposes. And the database refuses what does not fit: unknown customer, missing currency, negative stock. The refusal is the feature.

Pick one object, not the whole business. Usually customers and what they owe, or products and what they cost. Write down the five fields that matter and where they come from today. Put them in a real database (Postgres is fine, and free) with the constraints turned on. Feed it from the existing sources with AI data entry, confirmed by the person who already handles them.

Live with it for two weeks. If the team keeps using it without being asked, add the next object. If they do not, the friction is in the entry step, not in the database, and that is where to look.

What to keep

The spreadsheet, as a view. People are used to it. Let it read from the database instead of being the database.

What to stop

Typing the same fact twice. If a number exists in a PDF or a chat, a person should confirm it, not retype it.