The honest answer for most 15-person businesses is fix the spreadsheets — reorganize the data you already have, tighten who can edit what, add a form instead of free-typing. A custom build is worth its cost only when the spreadsheet’s failure is structural: no audit trail, can’t handle two people editing at once, can’t work where the work happens. One real shop needed the second kind, and the tell was concrete, not a feeling.
Start from the actual complaint, not the AI trend
“We should build an app for this” is usually a symptom of a real, specific complaint — “nobody knows what stage a job is in,” “the sheet gets overwritten,” “someone re-types this into a second system every day.” Every one of those has a spreadsheet-level fix worth trying first: a shared view instead of a personal copy, protected cells, a linked second sheet instead of manual re-entry. Most of the time that’s the whole fix, and it costs a lunch break, not a project.
The three questions that actually decide it
| Question | If the answer is “spreadsheet can do this” | If the answer is “it can’t” |
|---|---|---|
| Does more than one person edit it at the same time? | A shared, permissioned sheet handles this | Concurrent edits without a real backend silently overwrite each other |
| Does anyone need to know when a value changed, not just what it is now? | A version history tab, manually maintained, gets close enough | No real audit trail — a correction erases what happened instead of logging it |
| Does the work happen somewhere the spreadsheet can’t reliably reach? | Fine if everyone has a laptop and signal | A spreadsheet has no offline mode; the work stops when the connection does |
What it looked like when the answer was “build it”
A 15-person precoat and finishing shop had already tried the spreadsheet-and-paper version and an earlier native tablet app that didn’t fit how the floor actually worked — see the case study. The real tell wasn’t “spreadsheets are annoying.” It was that the shop floor has unreliable wifi, more than one tablet writes to the same job at once, and a correction to a finished record needs to show up as a correction, not overwrite the original. None of that is fixable inside a spreadsheet — it’s not a formatting problem, it’s a concurrency and audit problem, which is what a real backend is for.
What replaced it: Airtable as the system of record, a small backend that queues writes so a bad connection doesn’t create duplicates, and an offline-first app on the tablet. That’s a genuinely different shape of tool than a spreadsheet, not a nicer-looking one.
The other outcome: don’t build it
Just as often the honest scope call is the opposite. If the real problem is someone re-typing the same five fields into a second system a couple of times a week, deleting one of the systems is cheaper and more reliable than connecting or replacing either of them — no build required. That’s worth saying plainly because most people offering to build something don’t have a reason to tell you when not to.
Getting an honest answer on your case
This is exactly what a $400 blueprint is for: a written answer on which side of this your situation falls on, before either of you commits to a build that wasn’t needed. Book the free call to start there.