The spreadsheet was correct. So was the Airtable base that replaced it, and the Retool app bolted on top of that. Off-the-shelf internal tooling is the right call for most teams at most sizes, and any builder who tells you otherwise is selling. The interesting question is not build versus buy in the abstract. It is: what are the specific, observable signals that the bought tool has stopped scaling — and what does it actually cost to act on them.
The honest case for buying
For a team under roughly ten operators running one mostly-linear workflow, buying wins on every axis:
- Speed. An Airtable base or Retool app exists this afternoon. Custom software exists in six weeks.
- Cost. Seats are cheap at small counts. $50 per seat per month across eight people is $4,800 a year. No custom build competes with that.
- Maintenance. The vendor patches, hosts, backs up, and upgrades. You do none of it.
- Reversibility. Cancel the subscription, export the CSV, move on. A custom tool is a commitment.
Custom software is a liability with benefits. It should be built when the benefits are measurable, not when the spreadsheet gets embarrassing.
The five signals you have outgrown the tool
Off-the-shelf tools rarely fail by crashing. They fail by quietly capping how precisely your operation can work. Five signals, in the order they usually appear:
1. Permission granularity runs out
"Everyone with the link can edit" was fine at six people. At twenty-five, the new contractor can see every customer's billing history, because the tool's permission model stops at the table level and your requirement is row level. Workarounds appear: duplicated filtered views, a second base "just for contractors". Every workaround is a manual sync job that someone will forget to run.
2. Audit requirements appear
A customer dispute, an insurance renewal, a compliance review — and the question becomes: who changed this field, when, and from what value. Version history that says "edited by Sam on Tuesday" is not an audit trail. If the answer to "prove nobody altered this record" is a shrug, the tool's ceiling has arrived.
3. The workflow forks
Bought tools model one linear pipeline well: a record comes in, moves through stages, closes. Real operations branch. Rush jobs skip stages. Refunds run backwards. One-off exceptions become weekly exceptions. When the team maintains the real process in their heads because the tool cannot represent it, the tool has become a fiction that everyone politely updates.
4. Seat math crosses the build cost
Per-seat pricing is linear, and your headcount intends to grow. Thirty seats at $50 per month is $18,000 a year — $54,000 over three years — for a tool that fits the workflow at maybe the 70% level. A custom internal tool that fits at 100% runs $8k–15k for a focused build, $15k–50k with integrations and migration. When the three-year subscription total crosses the build quote, buying stops being the frugal option and starts being the familiar one.
5. The export-to-spreadsheet shadow system
The terminal signal. Someone exports to a spreadsheet "just to run the numbers". The spreadsheet grows formulas, then a tab per region, then it gets emailed around. Within a quarter, the exported copy is where decisions are made — and the system of record is neither system.
The drift failure mode
SPREADSHEET_STATE_DRIFT
Two stores of the same operational state — the tool and the exports — update independently with no reconciliation. Divergence compounds silently. Detection happens at the worst possible moment: a customer billed off one copy, a decision made off the other. By then neither store can prove it is correct, and rebuilding trust in the data costs more than the tooling ever did.
Drift is not a discipline problem, so it cannot be fixed with a policy memo. People export because the tool cannot answer their question inside the tool. The fix is a system that answers it.
What custom actually costs — against the real baseline
The comparison is never "custom versus free". The bought stack's real cost is seats plus workaround labor:
- Thirty seats at $50 per month: $54,000 over three years.
- Manual sync, export cleanup, and permission workarounds at four operator-hours a week: another $12,000–25,000 over three years, depending on loaded cost.
- One drift incident: unpriceable, until it prices itself.
Against that: a focused custom internal tool at $8k–15k, or $15k–50k where integrations, data migration, and per-object permissions are in scope. Add 15–20% of build cost per year in maintenance — custom is not maintenance-free, and any builder who omits that line is quoting fiction.
What the custom number buys, specifically, is the four things the bought tool capped: row-level permissions that match your org chart instead of the vendor's pricing tiers, an audit trail that records who changed what and from which value, a workflow model with your actual branches in it, and integrations that write back to the systems of record instead of exporting away from them. It does not buy prettier screens. If prettier screens are the complaint, stay with the vendor and change the theme.
A worked example. A 20-person logistics team on a $60-per-seat tool: $14,400 a year in seats, plus a coordinator spending roughly a day a week reconciling exports — call it $9k a year in loaded time. Three-year total: about $70k. The custom replacement — one branching workflow, row-level permissions, audit log, two integrations — quotes at $32k plus $5k a year to keep current. Three-year total: about $47k, and the reconciliation day disappears. The math is not subtle once the workaround labor is on the invoice. It is just rarely put on the invoice.
Constraint
Below roughly ten seats and one linear workflow: buy, and stop reading. The signals above are thresholds, not prophecy. A team that never hits them should never build. Custom internal tools earn their cost only when the off-the-shelf ceiling is measurably taxing the operation.
The migration path that does not bet the company
The classic failure is the big-bang cutover: build the replacement in private for four months, switch everyone on a Monday, then spend six weeks discovering which edge cases the old system was handling invisibly. The de-risked path is duller:
- Build alongside. The old tool stays live and remains the system of record. Nobody's workflow changes on day one.
- Cut over one workflow at a time. Start with the most painful, least risky workflow. Run it in the new tool for two weeks while the old tool could still take it back.
- Make the old system read-only, per workflow, as each cutover sticks. Read-only kills drift without deleting anyone's safety blanket.
- Migrate history last. Live workflows prove the data model first. Then history moves once, cleaned, into a schema that has already survived contact with reality.
This is how the ops console build replaced a nine-tab spreadsheet operation: workflow by workflow across six weeks, the spreadsheet demoted to read-only at each step, and no Monday on which everything was suddenly different.
The decision was never build versus buy. It is: which of the five signals are you already seeing, and what is drift costing while the seat invoices stay small enough to ignore. Internal tool builds start by pricing exactly that.