How do I know when our off-the-shelf software has stopped fitting the business?
The reliable signal is not a missing feature. It is the shadow system growing around the software: spreadsheets, group texts, and someone whose real job is retyping data between screens. Configuration gaps can be closed with setup work. Model gaps, where the software's idea of a customer or a job disagrees with yours, cannot. When you are paying labor to translate between the software and reality, the fit is gone.
Count the workarounds, not the missing features
Every software package is missing features. That by itself means nothing. What matters is what your team built to compensate. Walk the office and count the artifacts: the shared spreadsheet that tracks the thing the system will not track, the whiteboard, the recurring text thread, the export someone cleans every Monday morning.
Those artifacts are a measurement. Each one is a process your business runs that the software does not know about, which means the data about that process does not exist anywhere reportable. You can feel it when you ask a simple question and nobody can answer it without opening three tabs.
Configuration gap versus model gap
Before concluding you need something built, separate two very different problems. One is fixable by setup. The other is not fixable at all inside that product.
- Configuration gap. The software can represent what you do, but nobody set it up that way. Fields are unused, statuses are wrong, the tag list grew organically. This is an implementation problem and it is cheaper to fix than to replace.
- Model gap. The software's core objects disagree with your business. You sell maintenance memberships across multiple properties, and the system only understands a job at an address. You run two brands out of one dispatch board. No amount of custom fields fixes a model gap; it only hides it.
- Reporting gap. The data exists but the questions you ask cross systems, so no single product can answer them. This is the most common one, and it usually calls for a layer beside the software rather than a replacement of it.
The bill arrives as labor, not as a line item
The reason bad fit persists for years is that it never shows up as an expense. It shows up as a coordinator who spends part of every day reconciling, as jobs that get scheduled twice, as invoices that go out late because someone had to chase a number. Those hours are real, they compound with headcount, and they are invisible on a budget.
A useful exercise: pick your three most annoying weekly reports and estimate the human minutes spent producing them. Multiply by the year. That number is what you are already paying for the gap, and it is the honest baseline for any custom software conversation.
What to do before you replace anything
Replacing a system of record is the most expensive move available and often the wrong first one. Most teams discover that the operational software is fine and the failure is in the space between systems, which is where integration work belongs.
Write down the three questions you cannot answer today and the three tasks that require retyping. If they all live inside one product, fix the configuration. If they cross products, you need a connective layer, not a new platform. If your core objects are wrong, that is the case where building something is genuinely justified.
Topics: off-the-shelf · build vs buy · workarounds · data model
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.