How to size the cost of custom software before you have a quote
A framework for estimating custom software cost from the factors that actually move it, so you can challenge a proposal instead of comparing headline totals.
Most articles on this topic open with a range: "expect $50,000 to $500,000". That range is technically true and completely useless, because it spans everything from a small internal tool to a platform that runs a business.
Cost is driven by six factors, and only two are about features
The instinct is to estimate from the feature list. Feature count matters, but it is rarely the dominant term. These six factors, roughly in order of how much they move a total:
1. Integration surface. How many systems must this talk to, and do they have real APIs? Each integration carries discovery, error handling, credential management, and an ongoing maintenance obligation. An integration with an undocumented legacy system can cost more than the feature it enables. This is the single most common reason estimates are wrong.
2. Data migration. Moving history is almost always underestimated, because the cost is not in the transfer. It is in reconciling twenty years of inconsistent data that the old system tolerated and the new one will not. If nobody can tell you what percentage of existing records are clean, that is a discovery task before it is an estimate.
3. Regulatory and audit requirements. HIPAA, SOC 2, and similar regimes are not a checkbox at the end. They change the architecture, the logging, the access model, and the deployment pipeline. Adding them mid-project costs multiples of designing for them from the start. If you handle protected health information, read what a BAA actually obligates before you scope.
4. Number of distinct user roles. Each role with genuinely different permissions and workflows is close to a separate application surface. Five roles is not five times one role, but it is much more than one.
5. Availability and correctness requirements. A system that can be down for an hour on a Sunday is a different engineering problem from one that cannot. So is a system where a wrong number is embarrassing versus one where it is a financial restatement.
6. Feature count and interface complexity. This is where most conversations start and where the least variance actually lives.
A sanity check you can run yourself
Rate your project on each factor. The point is not the score, it is finding out where you cannot answer.
| Factor | Question to answer | Signal that it will cost more |
|---|---|---|
| Integrations | How many systems, and how many have documented APIs? | Any system where the answer is "we would have to ask the vendor" |
| Data migration | How many records, and what share are clean? | Nobody has profiled the existing data |
| Compliance | Which regime applies, and is there a signed agreement in place? | Compliance is described as "we will handle it later" |
| Roles | How many roles have genuinely different permissions? | More than three, or roles that can act on each other behalf |
| Availability | What is the cost of one hour of downtime? | The answer is "it cannot go down" without a budget attached |
| Scope | What is the smallest version that is still useful? | Nobody can name one |
That last row is the highest-leverage question in the whole exercise, and it is closely related to whether you should be building at all. A team that cannot describe a smaller useful version will build the large one, and the large one is where budgets go to die.
What makes a proposal trustworthy
You will not be able to verify the number. You can verify the reasoning behind it.
- It states assumptions explicitly. "Assumes the ERP exposes a REST API for orders" is a proposal you can correct. A total with no assumptions is a total you cannot argue with.
- It separates discovery from build. Anyone who quotes a fixed price for a system they have not examined is either padding heavily or planning to renegotiate. Both cost you.
- It names what is excluded. Data cleanup, training, third-party licences, and post-launch support are the four most common surprises.
- The phases have decision points, not just deliverables. You should be able to stop after discovery with something useful in hand. What that something is, we cover in what a two-week discovery must deliver.
The cost after launch
The build is the smaller half of the total cost of ownership. A working system needs dependency updates, security patches, integration repairs when a vendor changes an API, and changes as the business changes.
Budgeting nothing for that year one is the most reliable way to end up with a system that is unmaintained by year two, at which point you are paying for a modernization instead. If a proposal does not address what happens after launch, ask.
Where the work gets done also changes the arithmetic in ways that hourly rates hide. That is the subject of nearshore, offshore, or US, and how to tell whether a vendor can actually build it is evaluating engineering depth.
We publish how we work and what we protect in our security practices, and the way we scope is described under custom software development.