Anyone selling custom software will tell you that spreadsheets do not scale. They are right, eventually. They are usually wrong about when.
A spreadsheet that three people update, that has survived two years, and that everyone understands is a working system. Replacing it with software costs money to build, more money to maintain, and a month of everybody being slower while they learn the new thing. That trade is worth making at some point. It is not worth making because a vendor described your spreadsheet as unprofessional.
The signals that actually mean something
The clearest one is people re-typing data that already exists somewhere. An order arrives in one system and someone copies it into another by hand. That is not inefficiency you can train away — it is a missing connection, and every copy is a chance to introduce an error nobody catches until a customer does.
The second is that only one person can do a particular job. When a process lives in somebody’s head and a file on their laptop, the business stops when they are on leave. Software is one way to write that process down so it survives them.
The third is when the cost of a mistake has grown past the cost of preventing it. A stock count being wrong mattered less when you had forty items. At four thousand, with money tied up in each one, it is a different problem.
None of those is about volume, and volume is what most people cite. Twenty thousand rows in a spreadsheet is not a reason to build anything.
What it actually costs to own
The build is the part everyone compares. It is not where the money goes over time.
Software has to run somewhere, and that server bills monthly whether anyone uses the system or not. Dependencies release security patches you have to apply. Browsers change, and something that worked stops working. Someone on your side leaves and the new person needs training and access.
Budget the first year of running costs at a fifth to a third of the build, and expect that to continue rather than taper. Anyone quoting you a build price without raising this is either not thinking about it or hoping you will not.
The cheaper thing to try first
Before commissioning anything, find out whether the tools you already pay for can be connected. Most business software has an API, and a small integration that moves data automatically between two existing systems is a fraction of the cost of replacing either.
A lot of what gets scoped as custom software is really one missing connection, wrapped in a lot of screens nobody asked for. We would rather build the connection and tell you the rest is unnecessary — the alternative is a system you paid for and quietly stop using.
If you do build, build the smallest thing
The version that solves the one problem causing the most pain, in front of real users, within weeks. Not the platform that handles everything you might need in three years.
Every project we have seen go badly went the same way: a scope defined up front, then a steady accumulation of small reasonable additions until the timeline stopped meaning anything. Nobody agreed to that. It accrued. Shipping something small first is the only reliable way to find out which of the features on the original list nobody actually wanted.
