Nobody in this industry publishes pricing, which means every buyer walks into the conversation guessing. That is bad for buyers, and honestly it is bad for us too — half the calls we take are with people whose budget and expectations were never in the same room.
We do not publish a price list either, and it is worth being straight about why. The same sentence — “we need a customer portal” — describes a three-week build and a nine-month programme. A number written before anyone has looked at your systems is a guess wearing a suit, and you would be right not to trust it.
What we can do is tell you exactly what moves the number. Once you know that, you can read any quote — ours or anyone else’s — and understand why it says what it says.
What you are actually buying
Custom software spreads across roughly four tiers, and the distance between them is scope, not quality:
- A small scoped build — one automation, one integration, one workflow. Replacing a spreadsheet that has quietly become load-bearing.
- A focused internal tool — a single user role, a couple of integrations, real business logic underneath.
- A platform — several integrations, multiple distinct user types, migration from an existing system. This is where most engagements land.
- A full product — a SaaS build, a regulated domain, or a phased programme rather than a single project.
There is no minimum size of client here — only a minimum size of problem. If what you want is smaller than the first tier, an off-the-shelf tool is probably the better answer, and we will tell you that on the first call rather than the fourth.
The six things that actually drive the number
Day rates are the least interesting variable. Here is what genuinely moves cost.
1. How many systems it has to talk to
This is the single biggest driver, and it is the one buyers consistently underestimate.
One integration is a feature. Five integrations is an architecture. Each one brings its own authentication, its own rate limits, its own idea of what a “customer” is, its own outages, and its own field that is documented as a date but sometimes contains the string “TBC”.
Two systems that disagree about the same record is not an integration problem — it is a reconciliation problem, and reconciliation is where the hours go.
Rough guide: each meaningful integration adds real cost. Two integrations is not twice one; it is more, because now they have to agree.
2. Compliance and regulatory constraints
Building software that handles health records, financial data, or EU personal data is not the same job as building an internal dashboard. Audit logging, data residency, retention policies, access controls, encryption at rest, and the documentation to prove all of it — none of that is optional, and all of it is work.
This can add 30–50% to a build. It is not padding. It is the difference between software your compliance officer will sign off and software they will not.
3. Number of distinct user roles
An admin, a manager, and a field user are three different products sharing a database. Each needs its own permissions, its own views, its own workflows, and its own testing.
Cutting a secondary role from phase one is one of the most effective ways to reduce cost, and it is almost always reversible later.
4. Data migration
“We’ll bring the existing data across” is the sentence that most reliably breaks an estimate.
Your existing data has duplicates. It has records with a status that no longer exists. It has a field somebody repurposed in 2019 without telling anyone. Migration is not a copy; it is an archaeology project followed by a cleanup, and it is frequently a larger line item than the feature it enables.
If migration is in scope, it deserves its own estimate. If someone has folded it into “and we’ll import your data,” ask them how they plan to handle the records that do not validate.
5. How well the current process is understood
If the process you want to automate lives entirely in one experienced person’s head, discovery is going to take real time — and skipping it costs far more than doing it.
Companies with a documented process, a clear owner, and an existing understanding of their edge cases get cheaper software. Not because they are charged less, but because less of the budget goes into working out what the software should do.
6. Whether the outcome is actually defined
The most expensive projects are the ones where nobody agreed what success meant.
“Build us a customer portal” is not a scope. “Reduce the 40 hours a week our support team spends answering order-status questions, by giving customers self-service visibility into their orders” is a scope. The second one can be estimated, built, and — crucially — finished. The first one can be worked on forever.
Where estimates go wrong
Three patterns, and you can spot all of them in a quote.
The number excludes the parts nobody enjoys. Testing, deployment, error handling, monitoring, documentation, and the two weeks after launch when real users find the things nobody anticipated. A quote that omits these is not cheaper; it is incomplete, and you will pay the difference later at a worse moment.
Scope grows quietly. Not through a formal change request, but through a series of small reasonable additions in weekly calls. This is the most common way a project quietly doubles in cost, and it happens by consent rather than by ambush.
Cheap becomes expensive. The lowest bid frequently wins the project and loses the money, because it was priced on the assumption that everything goes well. Ask any vendor what happens to the price when it does not.
How to get a quote you can trust
Ask for three things.
A phase, not a project. Any vendor should be able to scope and fix-price a first phase that delivers something usable on its own. If they can only price the whole thing, and the whole thing takes nine months, you are being asked to make a nine-month bet on the strength of a sales call.
An explicit out-of-scope list. This is where the difference between two quotes usually lives. Make each vendor write down what they are not doing. The comparison gets dramatically clearer.
What happens when it goes wrong. Who pays when an estimate is missed? What is the process when a requirement turns out to be more complex than everyone assumed? A vendor with a straight answer has been here before.
The cheapest software is the software you do not build
Worth saying plainly, because it is the advice that costs us projects.
Some processes should be bought off the shelf. Some should be changed rather than automated. Some are painful once a quarter and do not justify a system at all. And some problems that look like software problems are actually a missing owner or an unwritten rule.
We say so when it is true. It costs us the engagement and it earns a client who comes back with the one that is worth doing.
If you want a real number for something specific, tell us the outcome you need and we will scope it properly — or tell you honestly that you should not build it.
More on how we approach custom software development.