Estimate custom software by decomposing scope into user journeys and integrations, applying an effort rate per component, then adding explicit contingency for unknowns. For a typical enterprise build, integration and data migration consume more effort than the screens users see, which is why feature-list pricing consistently underestimates real cost.
Why most software estimates go wrong
Cost estimates fail in a predictable pattern. Teams enumerate screens and reports, multiply by a rate, and produce a number that excludes everything that actually consumes engineering time. The visible surface of an enterprise system is a thin layer over identity, permissions, audit, integration and data quality work that users never see.
A second failure is treating requirements as fixed. In reality, discovery changes scope: you learn which of the eleven approval workflows are real, which three legacy integrations can be retired, and which regulatory constraints force an audit trail nobody budgeted for.
The result is a class of projects that appear to overrun by 100 percent when they were simply priced against the wrong baseline. A defensible estimate makes its assumptions visible so the conversation is about assumptions rather than about arithmetic.
Step one: decompose scope into estimable units
Break the system into user journeys rather than features. Each journey has an actor, a trigger, a set of steps and an outcome. A journey is estimable because you can count its steps, its decision points and its external dependencies.
Around the journeys sit the cross-cutting concerns that carry most of the risk: authentication and authorisation, audit logging, reporting and analytics, notification, file handling, search, and the integration surface. Estimate these separately and once, because they are shared.
The output of this step is a component list with a rough size for each: small, medium, large or extra-large. Resist the temptation to convert to hours immediately; sizing first and pricing second keeps the debate focused on scope.
- Capture each user journey with actor, trigger, steps and outcome.
- List cross-cutting concerns once and estimate them centrally.
- Enumerate every inbound and outbound integration with its protocol and owner.
- Record non-functional requirements such as availability, latency and retention targets.
Step two: apply effort drivers
Not every medium component costs the same. Effort is driven by ambiguity, integration count, data volume, regulatory exposure and the maturity of the surrounding engineering practice. A medium component inside a well-tested codebase with automated deployment is dramatically cheaper than the same component in a system deployed by hand once a quarter.
The table below shows typical effort distribution across a greenfield enterprise application. The proportions matter more than the absolute numbers, because they are what most estimates get wrong.
| Workstream | Share of effort | Why it is underestimated |
|---|---|---|
| Domain and data modelling | 10% | Feels like design, is actually the hardest engineering |
| Core business logic | 20% | The only part usually scoped accurately |
| Integrations and APIs | 22% | Third-party systems rarely behave as documented |
| Identity, roles and audit | 12% | Assumed to be a library, is a product decision |
| Data migration and cleansing | 14% | Legacy data quality is unknown until you look |
| Non-functional hardening | 14% | Performance and security targets change design |
| Deployment, observability, docs | 8% | Often excluded entirely from client estimates |
Step three: contingency and pricing model
Contingency is not padding, it is an explicit acknowledgement of uncertainty. Size it to what you do not yet know: 30 percent before discovery, 20 percent after discovery but before architecture is agreed, and 15 percent once the design is frozen. Making it a line item prevents it being quietly absorbed and then disputed.
Then choose a commercial model. Fixed price transfers risk to the vendor and therefore carries a premium. Time and materials keeps flexibility but requires strong product ownership. Milestone-based pricing with a capped envelope is the usual compromise for enterprise work, because it links payment to demonstrable increments.
Whichever model you choose, price the lifecycle: the build, the run cost, the enhancement backlog and the eventual exit. A system that costs less to build but triples operating cost is not cheaper.
- Fixed price: risk transferred, premium charged, change control essential.
- Time and materials: maximum flexibility, requires disciplined product ownership.
- Milestone-based: payment tied to demoable increments, best fit for most enterprises.
- Always fund a discovery phase before committing to a delivery number.
A reality check before you sign
Before committing, sanity-check the estimate against three ratios. Total cost per user journey should be in a plausible band for your domain. Operating cost should be a meaningful but manageable fraction of build cost, usually 15 to 25 percent per year. And the delivery timeline should leave room for a hardening phase that is not zero.
If any ratio looks impossible, the estimate is wrong rather than the project being exceptional. Ask which assumption would have to change and what it would cost to make it true.
Frequently asked questions
How much does custom enterprise software cost in 2026?
A focused internal system typically starts in the low tens of thousands of dollars, a mid-complexity platform with several integrations lands in the low hundreds of thousands, and a multi-region enterprise platform with compliance obligations and high availability targets runs higher still. Integration and data work, not screens, drive the spread.
Should I insist on a fixed-price contract?
Only if your scope is genuinely frozen and you accept the risk premium. For anything exploratory, milestone-based pricing with a discovery phase first produces a better outcome for both sides because it prices what is actually known.
How do I compare two very different vendor quotes?
Normalise them to the same scope and the same five-year horizon. Add the excluded items, add the operating cost, and compare the totals. Quotes that look cheap usually exclude integration, migration, hardening or documentation.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.