When a spreadsheet should become a database

Most businesses run on at least one spreadsheet doing a job nobody designed it for. Usually it works for years. Then it stops, and the signs are easy to miss until something goes wrong. Here’s how to tell where you are, and what to do about it.

Against interest

What spreadsheets are genuinely good at

A lot of writing on this subject comes from people with a database to sell. So before any of that: a spreadsheet is often the right answer, and replacing one with software somebody has to maintain is a real cost.

Strengths

• Anyone can open one and start working. No training, no onboarding, no licence to argue about.
• You can change its shape mid-thought. Add a column, try something, undo it.
• It’s the quickest way to work out what you actually need. Half the specifications I’ve been handed started life as somebody’s spreadsheet.
• For a few hundred rows that one person looks after, it’ll outlast most of the alternatives.

If that describes yours, stop reading. You haven’t got a problem.

Warning signs

Four signs yours has outgrown itself

1. 01

   More than one person needs it at once

   The moment two people edit the same file you're managing versions instead of doing the work. Shared cloud sheets help, and then they stop helping, usually when somebody sorts a column and breaks everyone else's row references.

2. 02

   You can't get answers out of it

   If answering a question means filtering, copying into another tab and finishing it by hand, the data's in there but you can't reach it. A database answers that in one query and gives everyone the same number.

3. 03

   The rules live in somebody's head

   Someone knows not to tick that box until the date in column F is filled in. Nothing in the file enforces it. That knowledge leaves when they do, and it's usually the expensive kind.

4. 04

   You keep history by copying the file

   Monthly backups with dates in the filename. Nobody can tell you what changed between two of them, or when, or who did it. That becomes urgent the first time somebody has to prove what happened.

The middle ground

Where Airtable and the rest fit

Between a spreadsheet and something built for you sits a whole category of tools: Airtable, Notion, Smartsheet, Softr on top of Airtable, Zapier or Make doing the automation. They’re good, and for plenty of businesses this is where the story ends.

What they do well: proper field types, so a date is a date. Real relationships between tables. Forms non-technical people can fill in without breaking anything. Permissions. An API if you need one later. You get most of the benefit of a database without hiring anybody.

Where they stop:

• Logic that doesn’t fit their model. Every one of these tools has a shape. Push past it and you end up with workarounds nobody can follow in six months.
• Volume. They all have record ceilings, and things get slow well before you reach the published limit.
• Per-seat pricing. Cheap for five people. Have a look at the number for fifty.
• Where your data sits. Fine for most work. Not fine under some compliance regimes, and worth checking before you build on it.
• Lock-in. Getting your data out is usually possible. Getting the logic out isn’t, because it was never really yours.

If one of these fits your problem, use it. I’d rather say so than build you something you didn’t need.

In practice

When it’s worth having something built

• When the record has to be a by-product of the work

  The smokehouse I built a HACCP system for had its food-safety requirements spread across paper forms and spreadsheets, filled in after the fact. The system now captures times, temperatures, batches and checks as the food is made, and tells the producer what's due next. A collection of disconnected requirements became one workflow, and the records that exist to satisfy a regulator became data the business can read: batch history, process consistency, recurring exceptions.

  HACCP Compliance →

• When several things need the same data

  Vii Dohtem runs a storefront, a separate Next.js site and the HACCP app from one engine. Three front-ends, one source of truth. That's hard to assemble out of separate tools, because each tool wants to own the data it holds.

  Vii Dohtem →

• When the way you work is the product

  Some businesses compete on how the work gets done. If that's yours, a generic tool won't model what makes you different, because it was built for whatever most customers needed. You end up bending the process to fit the software, which is backwards.

  M7SEO →

The move

What moving actually involves

It starts with your spreadsheet, not a blank page. The existing file is the specification. It shows what’s genuinely tracked, which columns people quietly abandoned, and where the exceptions are. I’d rather read it than interview you about it.

Your real data goes in before the features do. Loading actual records, mess intact, surfaces every bad assumption in the first week. Tidy sample data hides them until launch.

You keep the spreadsheet running for a while. A few weeks of both is how you find out what the new thing can’t do yet. It’s annoying. Do it anyway.

The first version does less than you’d expect. One job, done properly, so people switch because it’s easier. The rest follows once it’s in daily use.

Deciding

So which is it?

• A spreadsheet suits one maintainer, a few hundred rows, and nothing riding on it that you’d need to prove later.
• A no-code tool suits several people, a problem shaped like what the tool already does, and a headcount where per-seat pricing still makes sense.
• Something built for you earns its keep when the rules matter, when the record has to stand up to scrutiny, or when more than one system needs the same data.

Most of the businesses I talk to are in the middle one without having worked that out yet. If you’re weighing it up, bespoke software development is the wider picture, and sending me the spreadsheet is usually the quickest way to get a straight answer.