Why we don’t publish a range
Not evasiveness. Two identical-sounding briefs — “connect our ERP to our e-commerce platform” — can differ by five times in cost, and nothing visible from the outside tells you which one you have. One has documented APIs on both sides and one decision-maker. The other has an undocumented customisation layer, three departments with a veto, and a field mapping nobody has looked at since 2016.
A published range would make the first client feel overcharged and the second one plan for a number they’ll miss. The useful thing isn’t a number. It’s knowing which factors apply to you before you start asking for quotes.
If someone quotes you a firm price before understanding your environment, they’ve either assumed the easy version or they’re planning to recover the difference later.
What actually moves the number
1. How many systems it touches
This dominates everything else. A tool that stands alone is straightforward. The same tool reading from an ERP, writing to a warehouse system and notifying a CRM is not three times harder — it’s closer to eight, because each connection brings authentication, error handling, data mapping, and a failure mode somebody has to own.
Reducing the number of systems in scope, even by one, moves cost more than any other single decision available to you.
2. Whether what you have is documented
Undocumented legacy is the largest source of estimate variance in this industry. Reading code nobody wrote documentation for is slow, and no honest supplier can price it accurately without looking first. This is why we sell assessments separately rather than guessing and building the guess into a quote.
3. How many people have to agree
Rarely discussed and consistently underestimated. A project with one decision-maker moves at a different speed to one where operations, finance and IT each hold a veto. It isn’t only calendar time — requirements genuinely change when more people look at them.
4. Whether you’re fixing the process or automating it
Automating the current process is cheaper. Fixing it first costs more and produces a better result, because some steps exist only because of a constraint that disappeared years ago. We’ll usually recommend fixing, and we’ll tell you what that adds before you decide.
5. Data condition
The quiet one. Software is only as good as what goes into it, and inconsistent, duplicated or incomplete data is often discovered mid-project. Where data needs cleaning, reconciling or restructuring, that work is frequently larger than the build sitting on top of it.
6. Whether anyone will own it afterwards
Not a build cost, but it determines whether the build was worth paying for. Software with no owner decays within about two years regardless of how well it was made.
The approach changes the cost more than the requirement does
The same business outcome can often be reached several ways, and they don’t cost remotely the same. In rough order:
- Configure what you already own. Frequently free, and more often possible than people expect. Most businesses run a fraction of what their platforms can do.
- Connect what you already own. Integration is nearly always cheaper and less disruptive than replacing anything.
- Buy something for the gap. Where the process isn’t a differentiator and a mature product exists.
- Extend what you own. Custom work layered onto an existing platform rather than beside it.
- Build the differentiating part. Narrow, specific, and genuinely yours.
- Replace the system. Last, and only when security, reliability, maintainability, data integrity or cost make keeping it irresponsible.
We take no compensation from any vendor, so moving you up that list costs us exactly what moving you down it would. That’s the only reason this section can be written honestly.
How to make it cost less
- Start with one problem, one process, or one focused conversation. Proving the mechanics is worth more than breadth.
- Buy discovery on its own. It’s the cheapest way to turn uncertainty into a number, and the deliverable is yours wherever you take it.
- Reduce the number of systems in scope.
- Do the process mapping yourselves if you have the capacity. Plenty of clients do, and it genuinely reduces what we charge.
- Fix the data before building on top of it, not after.
- Ask whether it needs building at all. Sometimes a configuration change in something you already pay for does the job.
The cost that doesn’t appear in the comparison
The usual comparison is a licence fee against a build cost, which flatters whichever one is being sold. The comparison that matters runs over four years and includes hosting, updates, security patching, support, and the cost of extending it when the requirement changes.
Most quotes you receive won’t mention any of that. Ask for it in writing, from us and from anyone else.
When not to spend anything
A meaningful share of the conversations we have end with a recommendation to spend nothing, or much less than expected. The most common reasons:
- A product you already pay for does this, unconfigured
- The process shouldn’t exist, and automating it would entrench something worth deleting
- The volume doesn’t justify it — some manual work is genuinely cheaper than the software that would replace it
- Nobody internally will own the result
- Something else in the business needs solving first, and this would be built on sand
Sometimes the right decision is to wait. Sometimes it’s to simplify. Sometimes it’s to stop something altogether. We’re comfortable with all three.
How to get a real number
Tell us the problem. We’ll give you a sense of scale on the first call, free, before anyone writes a proposal — and if it’s wildly outside what you expected, we’d rather you found out in twenty minutes than three meetings.
Where responsible pricing needs deeper knowledge, we’ll say so and propose paid research and planning. You keep the deliverable whether you build it with us, build it internally, or take it elsewhere — and in some cases it carries into the project at no additional cost.
