You were told you need a real system. Usually you need a pipe, not a replacement.
A business keeps its inventory in a spreadsheet. Somebody sells them software to fix that. Eighteen months later the software is half-populated, the spreadsheet is still the one people actually update, and the operation is now maintaining two sources of truth instead of one.
This happens constantly, and the diagnosis behind it is usually wrong.
The spreadsheet is not the problem. It is doing three things well, and they are the three hardest things to get a team to do at all.
It is maintained by the person who knows the stock. Not delegated, not entered by an intern from a form — kept by whoever handles the goods and knows when something arrives, sells or changes condition.
It is structured. Columns are fields. Rows are records. It has been normalised over years by the friction of daily use, which is the only force that reliably produces a usable schema.
It is current, because updating it is the path of least resistance.
The spreadsheet already is the content management system. It simply has no publishing step.
That is the actual failure, and it is a much smaller one. The data terminates in a file on somebody’s machine instead of flowing to anywhere a buyer or a machine could see it.
Migrating to a “real” system attacks the wrong layer. It takes the one process that works and asks the person maintaining it to adopt a slower interface for the same result.
Predictably, they don’t. The spreadsheet survives because it is faster, and the new system drifts out of date within a quarter. Now the business has the original invisibility problem plus a licence fee and a stale database that contradicts the real one.
The tell is simple: if the proposed system does not make the maintainer’s day easier, it will lose to the spreadsheet, and it should.
A dealer in high-value watches and precious metals is the clearest version of this, because in that trade the spreadsheet is unusually rich. Every row already carries reference numbers, provenance, condition, specifications — because authentication demands it. You cannot trade seriously in that category with sloppy records.
So the data was excellent and completely unpublished. Every attribute a buyer would search for, and every attribute a retrieval system would need to classify an item, already existed in a maintained file that nothing could reach.
The work was not replacing that file. It was giving it somewhere to go.
An honest caveat, since this argument could be read as “never build software.” That is not the claim — and it would be a strange one coming from a studio that builds software.
The distinction is between replacing a working process and connecting one. A build that eliminates the spreadsheet and asks everyone to change how they work is usually replacing something that already functions. A build that reads the spreadsheet, validates it, and publishes it as structured, indexable pages is connecting it — the maintainer’s habits are untouched, and the output finally reaches an audience.
Some businesses genuinely outgrow the file: when several people need to write concurrently, when there is real transactional state, when an audit trail is required. Those are real triggers. “It’s a spreadsheet and that feels unprofessional” is not one.
Find the file the business actually runs on. Then ask one question:
Is anything in this file visible to someone who has not been sent it?
If the answer is no, the gap is a publishing step, not a system. That is a far smaller project than the one you were probably quoted, and it leaves intact the one process nobody had to be persuaded to maintain.
Three instruments on this site score exactly this — free, ungated, no email required to see a result.
Run the diagnostics →