What custom software costs: what actually sets the number

It's the first question in every meeting and the last one anyone will answer in writing. The website says "tailored solutions for your business" and underneath it there's a form.

Let's be direct: we don't publish a price table either, and it's worth explaining why before going further. A published range says very little and misleads quite a lot. Two companies asking for "the same thing" — automating invoice intake, say — end up with quotes that differ by a factor of three, depending on how many systems are involved and what state the data is in. A brochure figure becomes a number you have to correct later, and that conversation is worse than never having given one.

What we can do, and it's more useful, is tell you what moves the number. With that you can work out which side your case falls on before talking to anyone, and compare quotes on the merits.

The four things that set the budget

The price of a build is almost never set by the number of screens. It's set by these four, in this order of impact.

1. How many systems it has to touch. A system that lives alone is cheap. One that has to read from the ERP, write to the CRM and notify people over chat costs several times as much — not because of the code, but because of how many strange cases surface when two foreign systems have to agree on what a customer is.

If you're about to request quotes, count the systems involved. It's the best predictor you have.

2. How dirty your data is. This is the one that surprises everyone. If your data lives in spreadsheets where the same supplier is spelled six different ways, a real share of the project is cleaning and normalising. It isn't glamorous, it shows up on no screen, and it has to be paid for. The good news: you pay it once.

3. How many people have to change how they work. A system used by three people in purchasing rolls out in a week. One used by a hundred and twenty people across five branches needs training, permissions, a period running alongside the old process, and someone to absorb two months of "it didn't used to work like this". That's labour, and it belongs in the budget.

4. What happens when it fails. An internal dashboard that can be down for a day is not the same as the system that issues your invoices. The more expensive the failure, the more engineering surrounds it: monitoring, backups, retries, audit trails. That's the difference between "it works" and "it works at three in the morning on a Sunday with nobody watching."

What AI changed, and what it didn't

It changed the cost of building. Writing the code for a mid-sized system now takes a fraction of the time it took three years ago, and quotes reflect that: projects that were six months in 2022 ship in six weeks today.

It did not change the cost of understanding. Someone still has to sit next to the person entering delivery notes and discover the step that appears in no manual and without which nothing reconciles. That part doesn't speed up with models, and it's the part that decides whether the project is useful or just handsome software nobody opens.

That's why the diagnosis is quoted separately: it's the part AI didn't make cheaper, and it's what produces a number you can rely on.

Three ways of contracting that end badly

Hourly, with no ceiling. It sounds flexible and it's the most common trap. Nobody has an incentive to finish quickly, scope stretches on its own, and four months in you're arguing about a timesheet instead of looking at working software. If you do contract hourly, insist on at least a cap and a deliverable per period.

Everything fixed, twelve months up front. The opposite extreme and just as bad. Nobody knows in January what they'll need in September; what gets signed is a scope that's already stale by March. From then on, every necessary change becomes a contractual negotiation and the vendor starts defending the document instead of the outcome.

The cheapest of three quotes. When three quotes differ wildly, it's rarely because one firm is more efficient — it's because they understood different problems. The cheap one is usually quoting half of it. You'll find out in month four, when the first "that wasn't in scope" arrives.

What does work: short stages, each at a closed price. You quote what can be seen end to end, it gets built, it goes to production, and only then does the next stage get decided. If the vendor misjudged the estimate, that's their problem. If you changed your mind, you re-rank the priorities when the stage closes, with nothing to renegotiate.

How to compare two quotes without losing your mind

Three questions separate the serious from the rest:

1. Who owns the code? If the answer isn't "you do, repository handed over", you're renting, not investing. Ask before signing, not after.
2. What does "done" mean? The only acceptable answer is "running in production and used by your team". "Delivered for testing" isn't done; it's the start of the hard part.
3. What happens when the scope changes? Not if. When. If there's no clear, rehearsed answer, you'll discover it at the worst possible moment.

And one red flag: if a vendor throws a firm number at you on the first call, without having seen your systems or your data, that number isn't a quote. It's bait, and it will be revised upward.

When it isn't worth it

Worth saying, because it happens to us: there are cases where custom software is the wrong answer.

If you need standard invoicing, accounting or a by-the-book CRM, a product already does it well for a fraction of the cost. If your process will change completely next year because the business is still finding its shape, building now freezes a snapshot that will age badly. And if the real problem is that nobody has decided who owns the process, no system will fix it — it will just make it more visible.

Custom software earns its keep when the way you work is an advantage and nothing on the market models it. At that point, bending your company around a generic product costs more than building your own — and that comparison is made with numbers, not instinct.

How we do it

On the first call we give you an honest order of magnitude, so you know straight away whether we're in the same conversation and don't waste time. The closed number comes out of the diagnosis, with the scope in writing, and it holds: if we misjudge the estimate, that's our problem.

And if the diagnosis concludes there's no project, you keep the process map and the plan anyway. It happens, and we'd rather that than sell a build that isn't justified. You can see how we work or tell us about your case.