- Cost follows a few drivers: how much the software must do, how many systems it connects to, how messy the data is, which rules it must follow and who keeps it running.
- The exceptions, not the everyday path, usually take most of the effort.
- Building is only part of the bill. Running, supporting and changing the software is the rest, for as long as you use it.
- Compare a build with the full cost of the alternative, including the workarounds your team does today.
- A small first release is the cheapest way to learn what the whole system should cost.
Why there's no honest price list
Ask three builders to price "a customer portal" and you may get three very different answers. Usually none of them is wrong. Each one has pictured a different portal.
One imagined a login and a list of invoices. Another imagined the same thing plus document upload, approvals and a live connection to your accounting system. The third asked about your data and priced in a month of cleanup. The words were the same. The software was not.
So the useful question isn't "what does custom software cost?" It's "what makes this particular piece of software larger or smaller?" Once you know that, quotes become comparable, and you can decide where to spend.
The drivers that move the number
Roughly in order of how much they tend to matter:
| Driver | What pushes effort up | What keeps it down |
|---|---|---|
| Exceptions and rules | Many special cases, rules that live in people's heads, approvals that depend on who, what and how much | Rules written down before the build, and unusual cases handled by a person at first |
| Connected systems | Several systems to read from and write to, older systems with limited access, two-way syncing | One system as the home for each piece of data, one-way flows where possible |
| Data quality | Years of records in spreadsheets, duplicates, free-text fields that should be choices | Moving only the history you need, cleaning the rest once |
| Scope | Many distinct jobs, roles and screens in the first release | One painful job solved well, then the next |
| Who uses it | Customers or partners logging in, phones in the field, work without signal | Internal staff on desktop to start |
| Compliance and audit | Regulated data, detailed records of who changed what, security reviews | Knowing your obligations up front, so they're designed in rather than added later |
| AI steps | Testing on real examples, review screens, handling uncertain answers | AI used where the answer is easy to check, with a person approving |
Exceptions are the project
The everyday path through a process is often the smaller share of the work. The rush order, the customer with two billing addresses, the invoice that arrives before the purchase order: each of these needs a rule, a screen or a place to send it. A process with a few clear exceptions and one with dozens of unwritten ones can look identical in a demo.
Every connected system is its own small project
Connecting to your accounting system, your CRM or your ERP means learning how that system exposes its data, what it allows, how it fails and who administers it on your side. A second connection rarely costs half as much as the first, because each system has its own quirks. Our guide to connecting your systems covers the decisions involved.
Data can rival the build
Moving years of records out of spreadsheets or an old system is often underestimated. Someone has to decide what each column means, which duplicate wins and what to do with the record that fits nowhere. That takes builder time and, just as important, time from the people who know the data.
The cost after launch
Software that people rely on keeps costing something for as long as it runs. Plan for four kinds of cost:
- Running it. Hosting, databases, email delivery and any paid services it uses. AI services are usually billed by how much they process, so that line grows with volume.
- Keeping it current. The systems around your software change. Vendors update how their products connect, security fixes arrive, and app stores change their rules. Apple, for example, periodically requires new App Store uploads to be built with a recent version of its tools.
- Supporting it. Someone answers questions, fixes the odd broken record and watches for failures.
- Improving it. Once people use it, they ask for more. That's a good sign, and it needs a budget.
The UK government's service manual puts the live phase well: it's about supporting a service "in a sustainable way, and continuing to iterate." It also notes this doesn't always mean a full team all the time. Decide early how much ongoing work you expect, and who will do it.
Who maintains it changes the math
There are three common setups: your own developers take it over, the builder stays on, or a mix of the two. Each works. What doesn't work is assuming nobody will be needed. Whatever you choose, get the code, the hosting accounts and the documentation in your organization's name.
Comparing a build with buying
A license fee against a build quote is the wrong comparison. Count the full cost of each over several years.
| Count this | If you buy | If you build |
|---|---|---|
| Getting started | Setup, configuration, data import, training | Discovery, the first release, data migration, training |
| Ongoing | Licenses at the headcount you'll have, add-ons, price changes at renewal | Hosting, upkeep, support and improvements |
| Connections | Integration work or connector tools to fit it into your other systems | Built in, but each one has upkeep |
| Workarounds | Hours spent bending your process to fit, and spreadsheets on the side | Usually fewer, if the scope was right |
| Leaving later | Exporting data and retraining on the next product | You own the code, so the risk is losing the people who understand it |
Most of the time, buying wins, especially for work every company does the same way. Building earns its place when the work is how you compete, or when your rules are genuinely different. Our guide on custom software versus off-the-shelf goes deeper. Often the best answer is both: keep what you bought and build the gap around it.
One number belongs in every comparison: the hours your team spends on the problem today. Retyping, chasing, reconciling and fixing mistakes is the cost a build competes with. If you can't estimate it, measure it for two weeks before you ask anyone for a quote.
Phased releases keep the cost in your hands
The most reliable way to control cost is to buy software in pieces that each work on their own.
A first release solves one painful problem for one group of people, and it reaches them in weeks rather than months. What you learn from real use then shapes the next phase. If the first release is enough, you stop there, with something that works and no sunk cost in half-built features.
Phasing also makes estimates more honest. A builder can price a small, well-understood release tightly. Pricing a large system up front means pricing guesses, and guesses carry a margin for risk that you pay for either way. Our guide to scoping a software project covers fixed price, time and materials, and phased agreements.
How to get an estimate you can trust
The quality of an estimate depends on what you bring to it. The most useful inputs are:
- A walk-through of how the work runs today, with the person who does it.
- Real examples, including the strange ones.
- A list of the systems involved and who administers each one.
- One number that tells you the problem is fixed, such as hours per week or days of delay.
Then ask every builder the same questions. What's assumed to be out of scope? What happens when we find a new exception halfway through? What will it cost to run each month once it's live, and what makes that grow? Who owns the code and the accounts? Clear answers matter more than the size of the number.
What most guides miss
Cut scope, not quality. When a quote is too high, the instinct is to look for a cheaper builder. The bigger saving is usually a smaller first release. Corners cut on testing and error handling come back as support cost.
Your team's time is part of the cost. The people who know the work have to explain it, answer questions, test early versions and check migrated data. Plan for their hours, or the project slows down while they do their day jobs.
Unknowns are cheapest to find early. A short, paid look at the process before the build narrows the range more than any amount of back-and-forth over a proposal.
Be wary of precision too early. A detailed estimate for a large system, given before anyone has watched the work, is a sign that the risk has been priced in somewhere you can't see.
How we do it
We price after we've seen the work, usually through a process audit with a fixed fee that's credited in full if we build it. Then we quote the first release on its own, so you never commit to a whole system on a guess. We also stay on after launch to support and extend the system as your needs change. Tell us what you're trying to fix and we'll help you work out what it should take.
