Most operations teams don't set out to build custom software. They start with a general-purpose tool — a CRM, a spreadsheet, an off-the-shelf inventory system — and it works, for a while. The signs that it's stopped working are usually gradual enough that nobody flags the moment it happened.
If your staff maintains a parallel spreadsheet to track what the "real" system can't capture, that shadow process is your actual specification. It's usually more accurate than anything in a requirements document, because it evolved under real operating pressure.
When getting an accurate weekly number means someone exporting three systems into a fourth spreadsheet, the cost isn't just that person's time — it's the decisions that don't get made because the number arrives too late or isn't trusted.
Off-the-shelf vendors build for their median customer. If your workflow is a known edge case on their roadmap — the kind of thing that's been "under consideration" for two years — it's not coming.
A single manual export-import step between systems is an inconvenience. A recurring, multi-step workaround that someone has to remember to run is a structural gap the software should be closing.
If training someone on "how we actually use this system, as opposed to how it's meant to be used" takes longer than training them on the job itself, the tool has become the obstacle rather than the aid.
None of these signs alone means you need custom software built from scratch — sometimes the fix is a smaller integration layer, not a full rebuild. The useful next step is usually a short discovery conversation to map where the actual gap is, before committing budget to either direction.
A scoping call can tell you whether the fix is small or structural.