The decision to commission your own software fails in two ways, and both are costly.
Too early: you build before you really know what the program has to do, and the result needs changing before it's even finished. Too late: you struggle on for years with sticking plasters and spreadsheets instead of solving the problem, and you pay in staff hours what you saved on the invoice.
There are fairly reliable signs for each side.
Signs that it's still too early
Five people do the same task five different ways. If there's still no agreement on how the work gets done, whatever gets built will simply enshrine the version of whoever's in the meeting that day.
You can't explain the process on a whiteboard in ten minutes. If the explanation keeps needing "it depends" and "in that case it's different", the rules aren't settled yet. Settling them is management's job, and it's cheaper to do it first.
The main reason given is that the current platform is confusing. Sometimes it genuinely is. Often, though, what's confusing is what was put into it — and that same confusion will simply move house.
Signs that it's already too late
People are working full-time to compensate for the system. When someone spends half their day copying information between tools, you're already paying for the development — just every month, and with nothing to show for it.
You're turning down work because of the tool. When the answer to a customer is "our system can't do that", the cost is no longer just internal.
What sets you apart lives outside the systems. If the part of your work that outperforms the competition lives in a spreadsheet kept by one person, you're carrying a disproportionate risk.
What needs to be written down before you ask for a quote
It's not a fifty-page specification. It's six answers, and they fit on two pages:
- Who uses it, how many people, and how often.
- What goes in and what comes out: what's in front of the person when they start, and what's done when they finish.
- The rules: the decisions currently made from memory, and on what basis.
- The exceptions: the cases that break the rule, and how often they genuinely happen.
- Which systems it talks to, and in which direction.
- How you'll measure whether it worked, with a number and a deadline.
Writing this takes a week or two and is the highest-return part of the whole project. It's not unusual to conclude, halfway through, that nothing needs building at all — that changing two rules and connecting two systems would do.
What changes in the quote once this exists
Everything changes, in both directions.
Whoever quotes for a vague request has to protect themselves against uncertainty, and does so either through price or through a tight scope that then generates change requests at every step. With the six answers on the table, the proposal can be fixed in phases, priced by phase, and both sides know exactly what they're agreeing to.
On your side, you gain something more useful than a price: you can compare different proposals, because all of them answered the same question.
That's how we work on bespoke web applications — and it's why the first conversation is almost always about the process, not the technology.
Not sure which side you're on?
Tell us what your current tool won't do and how much manual work that forces. We'll tell you honestly whether it's worth building, or whether there's a shorter route.