When a custom app beats off-the-shelf software

The test: what is the spreadsheet for?

Almost every custom tool worth building starts life as a spreadsheet somebody is tired of. That spreadsheet is the most honest specification in the business — it is what people built when nothing they were given fit, which makes it a precise record of the gap.

So ask what it is doing. If it is a scratch pad, you do not need software. If it is the actual system of record — the thing people check before answering a customer, the file with four color conventions and one person who understands it — then you are already running custom software. It just has no permissions, no audit trail, no validation, and a single point of failure who takes holidays.

When buying is obviously right

Buy anything that is a solved, standardized problem where being different has no upside: accounting, payroll, email, calendars, helpdesk ticketing, e-signature. The vendor amortizes compliance, security patching, and edge cases across thousands of customers, and you will never out-build that economics for a process where you have no opinion.

Buy, too, when the gap you are feeling is small and generic enough that it is plausibly on someone's roadmap. A missing export or an awkward report is a bad reason to start a build.

When building wins

Build when the workflow is the thing you are actually good at — the sequence, the rules, the exceptions your competitors handle worse. Products are averages; if your process is deliberately not average, the average tool taxes you every day for the difference.

Build when the seat math has quietly inverted, and you are paying for licenses so occasional users can view a status. Build when the integration you need does not exist and the workaround is a person copying rows between two systems every morning — that is not a software gap, it is a data-movement problem wearing a job description.

The honest failure mode

Most custom-software budgets die on features that sounded essential in a kickoff and got opened twice. The risk is not that building is harder than buying — it is that a blank page invites scope nobody would have paid for as a line item.

The defense is sequencing: map the workflow as it actually runs, including the exceptions and the workarounds, and model the data and roles before any screens get designed. That scoping step is worth paying for on its own, because it either produces a build worth committing to or tells you the honest answer, which is sometimes that the tool you need is a better-configured version of the one you already have. That is the shape of how I scope custom applications.

Questions