Most of the time, the honest answer is don’t build it yet. That’s an odd thing for a company that builds custom software to publish, and that’s exactly why it’s worth publishing: if the answer is always “build it,” the person answering isn’t answering for you.
The five conditions that mean don’t build
| Condition | Why it means don’t build | What to do instead |
|---|---|---|
| The problem is disorganization, not a missing tool | A workflow scattered across email, paper, and three spreadsheets doesn’t need new software — it needs one of the existing tools used consistently | Pick one system of record and enforce it for a month before building anything |
| It hasn’t happened enough times yet | A one-off problem, however painful, doesn’t justify months of amortized cost | Solve it by hand once or twice and see if it recurs |
| Off-the-shelf software already does this | Most “we need custom software” problems are actually “we haven’t configured the tool we already pay for” | Spend a day reading the docs of what you already own before writing a spec |
| Nobody can say what “done” looks like | Custom software built against a fuzzy target gets rebuilt once, expensively, when the real requirement surfaces | Write the one sentence that says what changes when this ships — if you can’t, wait |
| The team doing the work wasn’t in the room | Software built without the people who’ll use it daily gets worked around, not adopted, no matter how well it’s coded | Get the actual users to describe their day before scoping anything |
What it looks like when the real answer is no
A 15-person precoat and finishing shop — the case study — is the honest counter-example to this whole post: that shop did need a build, because its failure mode was structural (no audit trail, concurrent writers, no offline mode — see the spreadsheet post). But the same shop also had problems that weren’t build problems. Their label costs were fixed with a $2,950 in-house printer, not software. Their AI use case was one feature bolted onto an already-correct database, not a new system. Not every complaint in the same shop pointed the same direction, and treating them all as “we need an app” would have been wrong for at least two of them.
The tell that it’s actually time to build
The flip side is worth stating just as plainly. It’s time to build when the failure is structural — more than one person needs to write to the same record at once and a spreadsheet silently loses data when they do; a correction needs to be logged, not overwrite history; the work happens somewhere with no reliable connection. Those aren’t preferences, they’re things a spreadsheet or off-the-shelf tool architecturally cannot do. When one of those is true, waiting longer just accumulates the cost of the workaround.
How to get an honest answer instead of a sales pitch
Ask whoever’s proposing the build to write down, in one page, what happens if you don’t build it — what keeps working, what stays a manual workaround, what it costs to live with for another year. If they can’t or won’t write that page, that’s the answer. A $400 blueprint is that page, written down before either of you commits to anything. Book the free call to start there.