# Custom software cost drivers

> The cost of custom software is driven by seven things: how many distinct user roles it serves, how many core workflows it supports, how many external systems it integrates with, how much existing data must be migrated, what compliance and audit requirements it must satisfy, how many workflows need AI judgement, and how deep the design goes. Integrations and migration carry the most unknowns. Phasing does not shrink the total, but it moves value earlier and lets each phase correct the estimate for the next.

Source: https://risendigital.io/guides/custom-software-cost-drivers  
Publisher: Risen Digital  
Updated: 2026-09-21

## At a glance

- **Biggest drivers:** Integrations and data migration, because each one depends on a system you do not control and rarely have documentation for.
- **Most underestimated:** The number of roles. Each role is a set of screens, permissions and edge cases, not just a login.
- **What AI adds:** Evaluation, guardrails and review loops around each workflow that needs judgement, on top of the workflow itself.
- **What phasing does:** It delivers something usable early and turns every later estimate into one based on evidence from the phase before.
- **What a good estimate contains:** A written scope, named assumptions, a phase plan, a list of unknowns, and what is excluded.

Two projects that sound identical in a first conversation can differ enormously in effort. The difference is rarely the technology. It is the number of distinct things the software must do, the number of systems it must talk to, and how much of the old world it must carry across. This guide names each driver so you can see your own project clearly and read any quote with confidence.

![A product team working together on laptops in an office](https://risendigital.io/images/experience/dev-team-1600.jpg)

## What actually drives the cost of custom software?

Effort scales with the count of distinct things the software must handle: roles, workflows, integrations, data to migrate, compliance rules, AI decisions and design depth. Each one adds screens, logic, tests and edge cases.

- **User roles** Every role sees different screens, has different permissions and hits different edge cases. An admin, a dispatcher, a field worker and a customer are four products sharing one database, not one product with four logins.
- **Core workflows** A workflow is a thing a person starts and finishes: raise a quote, approve a timesheet, book a job. Each needs its states, validations, notifications and reports, and the count of workflows is the best single predictor of build effort.
- **Integrations** Each external system brings its own authentication, data shapes, rate limits, failure modes and undocumented quirks. Reading from a system is one unit of work; writing back reliably is several.
- **Data migration** Old data is never as clean as anyone remembers. Duplicates, missing fields, inconsistent formats and records that only make sense to the person who typed them all have to be resolved before the new system can trust them.
- **Compliance and audit** If actions must be attributable, retained, reviewable or restricted by rule, the software needs audit trails, retention logic, permission models and reporting that a simpler tool would skip.
- **AI features** A workflow that needs judgement, such as classifying a request or drafting a response, adds a model integration plus everything that makes it safe: prompts, retrieval over your data, evaluation sets, confidence thresholds and a human review path.
- **Design depth** An internal tool used by a trained team can be plain. A customer-facing product must be self-explanatory on a phone, accessible, branded and forgiving, which multiplies the design and testing effort per screen.

## How big is your project, really?

Count the roles, workflows, integrations and AI decisions. The mix places you in a scope band that tells you how the work should be phased. No price appears, because a price without a written scope is a guess dressed as a number.

_Interactive on the web page: Size the scope from your own counts. The tool weights your counts of roles, workflows, integrations and workflows needing AI judgement to place the project in one of four bands: a focused tool, a standard product, a complex system or a platform. Integrations weigh most, then AI workflows, then plain workflows, then roles. It also suggests a number of releases at roughly four workflows each and flags the integrations to prototype first. The lesson is that a project with two roles and eight integrations is larger than one with six roles and none, even though the second sounds bigger._

## How does phasing change the cost?

Phasing does not make the whole smaller, but it delivers value earlier, spreads the spend, and replaces guesses with evidence after each release. It also lets you stop early if the first phase was enough.

A single big release means everything is estimated at the start, when the least is known, and nothing is usable until the end. A phased plan puts the workflow that unblocks the most people first, ships it, and uses what was learned to estimate the next phase. Unknowns are resolved one at a time rather than priced in as risk.

The order matters. Integrations go early, even as throwaway prototypes, because they hold the surprises. Migration is planned early and executed late, with a rehearsal. AI features come after the plain workflow works, because a model can only be evaluated against real data flowing through a real process. Design depth is added where usage proves it is needed, not everywhere at once.

| Driver | One big release | Phased releases |
| --- | --- | --- |
| Integrations | All priced up front as risk | Prototyped first, priced once understood |
| Workflows | All built before anyone uses one | The most valuable ships first, the rest re-estimated on evidence |
| Migration | One cut-over at the end | Rehearsed early, executed when the receiving workflow is proven |
| AI features | Designed before the data exists | Added once real cases flow, evaluated against them |
| Design depth | Every screen polished | Polished where people actually spend time |

## What should a good estimate contain?

A written scope you can recognise your business in, the assumptions it rests on, a phase plan, a list of unknowns with how each will be resolved, and a clear statement of what is excluded.

- **A scope in your words** Roles, workflows and integrations named as your team names them. If the estimate reads like a template, it was not built from your project.
- **Named assumptions** That the accounting system has a usable API, that the old data has a unique customer identifier, that one person can make decisions for the business. Each assumption that fails changes the effort.
- **A phase plan with a first usable release** What ships first, who uses it, and what has to be true for the next phase to start.
- **The unknowns, and how they will be resolved** A short list of the things nobody can know yet, each with a cheap way to find out, such as a prototype integration or a sample migration.
- **What is excluded** Hosting, support after launch, training, data cleaning, third-party fees. Not necessarily in the quote, but never left unsaid.

## What should you ask about any quote?

Ask what would make the number change, what happens when an assumption fails, what you own at the end, and what it costs to change something after launch.

1. **What would make this number go up, and by how much?** A good answer names specific drivers: an extra role, an integration that turns out to have no API, data that needs cleaning. A vague answer means the risk is hidden in the number.
2. **Which assumptions is this built on?** You should be able to check each one before signing. If the estimate contains none, ask where the risk went.
3. **What is in the first release, and could we stop there?** A first phase that is usable on its own is the best protection you have. If nothing is usable until the end, ask why.
4. **What do we own when it is finished?** Code, documentation, the data model, the accounts for hosting and the model provider. Ownership that is not written down is not ownership.
5. **How are changes handled after launch?** Every system changes. Ask how a small change is requested, estimated and delivered, and who on your side can make one without the original team.
6. **How will the AI parts be evaluated?** Ask for the test set, the acceptance threshold and the review path for cases the model gets wrong. An AI feature with no evaluation plan is a demo.

## Frequently asked questions

**Q: Why do two quotes for the same project differ so much?**  
A: Usually because they are not for the same project. One vendor counted three roles and the other counted one; one priced the integrations as unknown risk and the other assumed they would be simple. Put the quotes side by side against the seven drivers and the difference almost always shows up as a difference in scope or assumptions.

**Q: Does using AI make custom software cheaper to build?**  
A: It lowers the cost of writing conventional code and speeds up the plain workflows. It does not remove the cost of understanding your process, integrating your systems or migrating your data, and it adds the cost of evaluating any AI feature the software itself contains.

**Q: Is a fixed price or a phased engagement better?**  
A: A fixed price feels safer but bakes every unknown into the number as risk. A phased engagement with a fixed first phase gives you a firm commitment on the part that can be known and evidence for the rest. Ask for a fixed price on phase one and a re-estimate after it.

**Q: What is the most common reason custom software goes over budget?**  
A: Discovering the drivers late. An integration with no documented API, data that needs cleaning by hand, or a fourth role that nobody mentioned. Each is cheap to find early with a prototype or a sample, and expensive to find mid-build.

**Q: How much should design cost relative to the build?**  
A: It depends on who uses the software. An internal tool for a trained team needs clarity, not polish. A customer-facing product must work unaided on a phone, which means more design, testing and edge cases per screen. Match the depth to the audience.

## Related pages

- [Build vs buy AI software](https://risendigital.io/guides/build-vs-buy-ai-software)
- [How to choose an AI development partner](https://risendigital.io/guides/how-to-choose-an-ai-development-partner)
- [The RISE method](https://risendigital.io/guides/the-rise-method)
- [90-day AI implementation roadmap](https://risendigital.io/guides/90-day-ai-implementation-roadmap)