When a spreadsheet stops being enough

The moment you have outgrown it

Nobody decides to replace a spreadsheet. What happens is that someone asks a question the spreadsheet cannot answer — who is working this case, how long has it been waiting, did anyone follow up — and the answer takes an afternoon of asking around.

That afternoon is the real signal. Not the row count. A spreadsheet with forty thousand rows is fine if one person reads it. A spreadsheet with four hundred rows is already broken if six people need to change it at once and nobody can tell who changed what.

The three symptoms that actually predict the need, in order of how reliably I have seen them: two people editing the same thing and one silently winning; a process that only one volunteer understands; and status that has to be reconstructed by reading a chat thread. If you have all three, the coordination has already outgrown the tool, and every month you wait makes the migration bigger.

The question that decides the whole project

When someone quotes you for custom software, the questions they ask in the first hour tell you most of what you need to know. The ones that matter are not about technology. They are about the shape of your work.

Here is a real example. A genetic genealogy organisation helps people identify a biological parent. Straightforward: one client, one case. Except a client sometimes searches for both parents — and now you have one person, two searches, two different researchers, two timelines, and two outcomes that may not arrive together.

That single wrinkle changes the data model, the assignment logic, the notification rules, the reporting and the definition of the word 'closed'. If it surfaces in the first conversation, it gets designed for. If it surfaces in month four, it gets bolted on.

What a bolted-on answer costs

In that example the bolted-on answer was to create two independent cases and link them together afterwards, by parsing the text of case communications to work out which ones belonged to each other.

It worked. It also had three properties nobody wanted. The links depended on a text format, so a change in how people wrote notes broke the links — silently, with no error and no alert. There were two places recording the same relationship, and they could disagree. And nothing kept the two halves in step, so one could be marked solved while the other sat in progress.

None of that is exotic. It is what happens when a structural question gets a procedural answer. The fix was a real relationship in the database — one field, conceptually trivial, and considerably more expensive to introduce at nine thousand cases than it would have been at nine.

This is the strongest argument for spending real time on discovery, and it has nothing to do with anyone's professionalism. The cost of a wrong model is not the rework. It is the months during which the wrongness is invisible.

Migration is not the last step, it is the project

Every proposal has a line near the end that says 'data migration'. It is usually the most underestimated line in the document, because your existing data does not have the shape your new system needs, and the difference is where all the work lives.

Real spreadsheets contain a column that means two things depending on another column. Dates in four formats. Statuses that were renamed in 2023 and half-updated. Names entered as 'Smith, J' and 'J Smith' and 'jsmith'. People deduce this stuff effortlessly and software cannot deduce any of it.

So the honest sequence is: migrate early, migrate repeatedly, and treat the first import as a discovery exercise rather than a delivery. The import that moved nine thousand historical cases into the system I mentioned ran many times before it ran for real, and each run surfaced a rule nobody had ever written down.

Security is a question about defaults, not promises

If your organisation holds anything sensitive — and case notes, family relationships and intake forms all qualify — then 'is it secure' is too vague to be answerable. Ask about defaults instead, because defaults are what survive a busy month.

Three worth asking. Is sensitive data encrypted in the database itself, so that a leaked backup is not a leaked client list? Can you rotate the key without re-entering everything? And who can see what — is access decided per role, or does everyone with a login see everything because that was simpler?

The fourth question is the one that separates a maintained system from an abandoned one: what happens when a dependency is found to be vulnerable? A good answer is specific. On the systems I maintain, the build fails on any high or critical advisory unless it has been individually reviewed and written down, with a date and a trigger for re-review. That is not sophistication, it is bookkeeping — but it is the bookkeeping that stops a known hole sitting open for a year because nobody owned it.

Ask what happens when you want to change a word

The clearest predictor of whether you will still be happy in two years: can your own team change things without calling anyone?

Not architecture. Words. Can you rename a status, add a resource, change the text on a form, add a volunteer role? If every one of those is a support request, you have not bought software, you have rented a dependency. Budget for it accordingly, or insist otherwise up front.

Related, and awkward to ask but worth it: if you and I stop working together, what do you take with you? The answer should be 'the code, the data, and the ability to hand it to someone else'. Anything less is a commercial arrangement dressed as a technical one.

When you should not build anything

Plenty of organisations that ask me for custom software should not have it. If you need a website with a donate button, use a page builder. If you need to sell twenty products, use Shopify. If you need to run a mailing list, use the mailing list product. Custom is worth it when your process is genuinely yours and no product models it — which is exactly the case when your coordination is the thing that makes you good.

The test I use: if you can describe what you need by naming an existing product and three complaints about it, buy the product and live with the complaints. If you cannot name a product that comes close, that is a real signal.

The second test is arithmetic. Per-seat software that fits gets cheaper than custom for a long time. It stops being cheaper when you are paying for forty seats, most of whom are volunteers who log in twice a month, or when you are paying for the tier that unlocks the one feature you actually need.

The short version

Ask a prospective developer to describe your hardest case back to you. Ask when you will first see real data in the system. Ask what happens when a dependency turns out to be vulnerable. Ask what you can change without them. Ask what you keep if they disappear.

Five questions, none technical, and the answers will tell you more than any portfolio — including mine.