What drives the cost of custom software, and why estimates vary so much
No prices, on purpose. The seven factors that move the cost of custom software, why two honest estimates can differ by a factor of three, and how to narrow it.
The short answer
Custom software has no list price because it is not a product; it is a description made real. What it costs depends on what the description contains, and most descriptions leave the expensive questions open. Two honest suppliers can read the same brief and estimate three times apart, because each filled the gaps with a different system.
There are deliberately no amounts here. What follows is the list of factors that move the number, so you can close the gaps yourself and get estimates that mean something.
The seven factors
| Factor | What moves the cost up | How to keep it down in a first version |
|---|---|---|
| 1. User roles | Each kind of user (customer, staff, admin, partner) needs its own screens, permissions and tests | Start with one or two roles |
| 2. Integrations | Every external system: accounting, CRM, payments, email, planning. Each has its own API, quirks and failure modes | One integration that earns money; the rest later |
| 3. Data complexity | Many related records, history that must be kept, imports from old systems | Simple model first; migrate old data separately |
| 4. Process definition | Undefined exceptions get discovered during development, when they are most expensive | Write the process down, including what happens when it goes wrong |
| 5. Compliance | Personal or sensitive data, audit trails, retention rules, accessibility, sector regulation | Know which apply before design, not after |
| 6. Scale | Thousands of concurrent users, real-time updates, large files | Build for today’s volume with a path to more |
| 7. Build versus configure | Bespoke logic costs more than a well-chosen library or service | Buy the standard parts, build the part that is yours |
Why the spread is so wide
Hourly rates differ between suppliers by a modest factor. Estimates for the same brief differ by much more. The difference is assumptions: one supplier assumed two user roles, another five; one assumed the accounting integration is a simple export, another a two-way sync; one assumed the exceptions are rare, another read them as the core of the system.
How to narrow it before you ask
- Write the process down. Step by step, including the exceptions. If nobody can, the first project is the writing, not the software.
- Count the roles. Every kind of person who will log in, and what each may do.
- List the integrations. Every system the software must talk to, in which direction, how often.
- Name the compliance requirements. Personal data, sensitive data, audit, retention, accessibility.
- Describe the smallest useful first version. One question it must answer, for one kind of user. Ask for that estimate first.
The other half of the cost
Over five years, the build is roughly half. The rest is hosting, monitoring, security updates, dependency updates, small changes and support, and it depends on the same seven factors. A system with many integrations costs more to keep running because integrations change. A system with sensitive data costs more to keep compliant. Ask for the running cost estimate alongside the build, and compare five-year totals.
What this means for you
Before you request estimates, answer the seven factors on one page and describe the smallest first version. You will get numbers that are close to each other and close to the truth, and you will have done the thinking that decides whether the project succeeds. Estimates do not vary because suppliers are guessing wildly. They vary because the brief let them.
Frequently asked questions
Why can't a supplier just give me a price from a description?
They can give a range, and a wide one, because a description leaves the expensive questions open: how many kinds of users, which systems it talks to, what happens in the exceptions, how the data must be protected. Two developers reading the same paragraph picture two different systems. The scope conversation closes those questions and narrows the range.
Is a low estimate a warning sign?
It is a sign that the supplier pictured a simpler system. Sometimes that is insight and sometimes it is what they missed. Ask them to walk through the seven factors; if they have answers for each, the low number may be right. If they have not thought about integrations or exceptions, the number will grow.
What is the cheapest way to reduce the cost?
Reduce roles and integrations in the first version, and define the process before development starts. A first version for one kind of user with one integration, on a well-defined process, costs a fraction of the full picture and answers most of the questions the full picture depends on.