On this page
In short
- Cost follows scope: the workflows, the systems it connects to, the data it moves and the standards it must meet. Technology choice matters less than most buyers expect.
- Integrations and data migration are the most common sources of surprise, because their difficulty depends on systems the builder hasn't seen yet.
- Budget for the whole life of the system: hosting, licenses, your own staff's time, support and upgrades, not only the build.
- Two quotes can only be compared once they describe the same scope. Ask each firm to list what's out, what they assumed, and what drives their price.
Why a price range without a scope doesn't help
Published price ranges for "a web app" or "a dashboard" span so widely that they can't anchor a budget request. The same words cover a single screen reading one database and a multi-site system with sign-in, integrations, audit trails and a mobile app. Any number quoted before those differences are known is a guess, and a guess in a budget request tends to become a commitment.
A more reliable route is to understand what the price will depend on, write those things down, and let firms quote against that. The rest of this guide is about making that list.
What actually drives the cost
Estimates are built from the same handful of factors. Knowing where your project sits on each one lets you predict which way a quote will move and have a better conversation about it.
The main cost drivers of a custom software project and what pushes each one up
Workflows and roles
- Pushes cost up
- Many distinct user roles, each with its own screens, approvals and exceptions
- Keeps it contained
- A small number of roles and a clearly described main path, with exceptions listed
Integrations
- Pushes cost up
- Writing to other systems, undocumented interfaces, systems nobody on your side can explain
- Keeps it contained
- Read-only access through a documented API, database view or historian interface
Data migration
- Pushes cost up
- Years of inconsistent data from spreadsheets or an old app that must all move and reconcile
- Keeps it contained
- Moving only current records, or starting fresh with the old data kept read-only
Platforms
- Pushes cost up
- Web, iOS and Android, offline use, and support for older devices
- Keeps it contained
- One platform first, usually web, with mobile added once the workflow is proven
Security and compliance
- Pushes cost up
- Detailed audit trails, formal security reviews, regulated data, strict hosting rules
- Keeps it contained
- Your existing single sign-on and standard controls, with requirements known up front
Performance and availability
- Pushes cost up
- Real-time data, large volumes, and systems that must stay up through outages
- Keeps it contained
- Refresh rates and uptime agreed per screen, based on what the business actually needs
Infrastructure
- Pushes cost up
- No cloud account or pipeline yet, so foundations are part of the project
- Keeps it contained
- An existing account and deployment standards the project can follow
Uncertainty
- Pushes cost up
- Unfamiliar systems, AI features whose accuracy isn't known yet, open questions
- Keeps it contained
- A short discovery or proof of concept that answers the open questions first
| Driver | Pushes cost up | Keeps it contained |
|---|---|---|
| Workflows and roles | Many distinct user roles, each with its own screens, approvals and exceptions | A small number of roles and a clearly described main path, with exceptions listed |
| Integrations | Writing to other systems, undocumented interfaces, systems nobody on your side can explain | Read-only access through a documented API, database view or historian interface |
| Data migration | Years of inconsistent data from spreadsheets or an old app that must all move and reconcile | Moving only current records, or starting fresh with the old data kept read-only |
| Platforms | Web, iOS and Android, offline use, and support for older devices | One platform first, usually web, with mobile added once the workflow is proven |
| Security and compliance | Detailed audit trails, formal security reviews, regulated data, strict hosting rules | Your existing single sign-on and standard controls, with requirements known up front |
| Performance and availability | Real-time data, large volumes, and systems that must stay up through outages | Refresh rates and uptime agreed per screen, based on what the business actually needs |
| Infrastructure | No cloud account or pipeline yet, so foundations are part of the project | An existing account and deployment standards the project can follow |
| Uncertainty | Unfamiliar systems, AI features whose accuracy isn't known yet, open questions | A short discovery or proof of concept that answers the open questions first |
Notice what isn't on the list: the programming language, the framework or the number of pages in a design mock-up. Those matter for maintainability, but they rarely explain why one quote is several times another. Scope does.
Integrations and data: where estimates go wrong
Much of a project's risk sits where it touches systems the builder doesn't control. An integration that looks like one line in a proposal can be a small task or a large share of the project, depending on details only your team knows. Before asking for quotes, write down for each connected system:
- What it is and which version, for example SQL Server, Oracle, an AVEVA PI historian, a Kepware OPC UA server or a SaaS product.
- Which direction data moves. Reading is almost always simpler and safer than writing.
- How it's reached: a documented API, a database view, a file drop, or nothing yet.
- Who owns it on your side, and whether they'll have time to answer questions and grant access.
- Whether a test copy exists, or whether development would have to happen against production.
For data migration, a short sample of the real data, anonymized if needed, tells a builder more than any description. Messy data isn't a problem in itself; not knowing about it until the build is. Our guide to replacing a spreadsheet or Access database goes deeper on the data side.
Budget for the whole life of the system
The build is the most visible cost, but not the only one. A budget request that covers these as well is easier to defend and less likely to be reopened later:
Costs to budget for beyond the build itself
Hosting
- What it covers
- Cloud or server costs for each environment, which grow with data and users
- Who to ask
- The builder, with an estimate based on expected usage
Licenses and services
- What it covers
- Third-party software and services the system relies on, such as connectivity plug-ins, email or SMS providers, or AI APIs
- Who to ask
- The builder and your vendors
Your team's time
- What it covers
- Subject-matter experts, reviewers, IT and security staff during the project
- Who to ask
- Your own managers; it's easy to leave out
Support and maintenance
- What it covers
- Fixes, dependency and security updates, and small changes after launch
- Who to ask
- Your IT team, or quoted separately by the builder
Planned upgrades
- What it covers
- Platform and runtime updates, new OS versions for mobile apps, integrated systems being upgraded
- Who to ask
- Your IT team and the builder
| Cost | What it covers | Who to ask |
|---|---|---|
| Hosting | Cloud or server costs for each environment, which grow with data and users | The builder, with an estimate based on expected usage |
| Licenses and services | Third-party software and services the system relies on, such as connectivity plug-ins, email or SMS providers, or AI APIs | The builder and your vendors |
| Your team's time | Subject-matter experts, reviewers, IT and security staff during the project | Your own managers; it's easy to leave out |
| Support and maintenance | Fixes, dependency and security updates, and small changes after launch | Your IT team, or quoted separately by the builder |
| Planned upgrades | Platform and runtime updates, new OS versions for mobile apps, integrated systems being upgraded | Your IT team and the builder |
Our guide to custom web apps vs. low-code compares a custom build with a licensed platform, and what a proper software handover should include covers what you need in hand to run the system afterwards.
How to set a budget before you have a quote
- Write the problem down in business terms. What slows the business down today, who feels it, and what "better" looks like. This anchors every later trade-off.
- Sort features into must, should and could. The musts are the first release; the rest can be quoted as options so you can see what each one adds.
- List the systems and data involved, using the questions in the section above.
- Decide the constraints: where it must be hosted, how users sign in, and which reviews it must pass.
- Split the project if the unknowns are large. A small, separately priced discovery or proof of concept, followed by a price for the build, often costs less than a large quote padded for risk.
- Set aside a contingency for changes. People ask for different things once they see working software. Agree how changes will be priced before the project starts, not during it.
Comparing quotes like for like
When quotes differ widely, the firms have usually understood different projects. Before comparing prices, put each proposal through the same checklist and note where one covers something another doesn't:
What to check in each quote before comparing prices
Pricing model
- What to look for
- A fixed price for a defined scope, or an hourly estimate where you carry the risk of it being wrong
Scope detail
- What to look for
- Features described as behavior, with an explicit out-of-scope list
Integrations
- What to look for
- Each system named, with direction and access method, not "connect to your systems"
Assumptions
- What to look for
- What the price depends on, and whether any assumption quietly moves risk back to you
Acceptance criteria
- What to look for
- How each part will be checked and signed off
Hosting and environments
- What to look for
- Whose accounts, how many environments, and whether infrastructure is defined as code
Ownership
- What to look for
- Code, infrastructure and documentation in your repositories and accounts
Handover
- What to look for
- Documentation, runbooks, training and access transfer, included in the price
Change process
- What to look for
- How changes are raised, priced and approved
After launch
- What to look for
- Whether a warranty or support is included, and how anything further is priced
Who does the work
- What to look for
- Who is on the project day to day, and how much senior attention it gets
| Check | What to look for |
|---|---|
| Pricing model | A fixed price for a defined scope, or an hourly estimate where you carry the risk of it being wrong |
| Scope detail | Features described as behavior, with an explicit out-of-scope list |
| Integrations | Each system named, with direction and access method, not "connect to your systems" |
| Assumptions | What the price depends on, and whether any assumption quietly moves risk back to you |
| Acceptance criteria | How each part will be checked and signed off |
| Hosting and environments | Whose accounts, how many environments, and whether infrastructure is defined as code |
| Ownership | Code, infrastructure and documentation in your repositories and accounts |
| Handover | Documentation, runbooks, training and access transfer, included in the price |
| Change process | How changes are raised, priced and approved |
| After launch | Whether a warranty or support is included, and how anything further is priced |
| Who does the work | Who is on the project day to day, and how much senior attention it gets |
A lower price with a long assumptions list and a thin out-of-scope section may cost more in the end than a higher one that has already priced the hard parts. The sample written scope shows the level of detail that makes a fixed price meaningful, and the sample handover package shows what "handover included" can look like in practice.
Want a quote you can compare?
On a scoping call we'll work through the cost drivers above for your project. If it's a fit, we hold one to two weeks of working sessions with your key people, then you get a written scope and one fixed price that you can put side by side with any other proposal.
Not ready to talk yet? Draft a project brief first
Questions that explain a price
Ask every firm the same questions
- Which three parts of this project drive most of your price?
- What would you cut or defer to bring the price down, and what would we lose?
- Which of your assumptions, if wrong, would change the price the most?
- What is explicitly not included?
- How are changes priced, and who approves them?
- What does the price include after launch, and how is anything beyond that priced?
- Who will actually do the work, and who do we talk to day to day?
The answers tell you more than the totals. A firm that can explain its price in terms of your scope has thought about your project; one that can't may be pricing a template.
Cost depends on who builds it, too
Quotes from an outside firm are only one way to get software built. Hiring in-house turns the cost into salaries and management time; staff augmentation turns it into an hourly or monthly rate under your direction; a low-code platform turns it into licenses. Each shifts different risks onto you, which matters as much as the headline number. Our comparison of in-house, staff augmentation or a software firm sets them side by side.
We quote each project at one fixed price against a written scope, after a scoping call and one to two weeks of working sessions with your key people, and price any change in writing before work on it starts. Support after launch is quoted separately. Our How we work page explains how that works, and how fixed-price software projects work covers what makes a scope strong enough to price.
See it applied
Share this guide
Related services
Topics