Software strategy
How Much Does Custom Software Cost? The Cost Drivers and How to Scope Them
Nobody can give an honest price for custom software without a scope, because cost follows what the software has to do, for whom, connected to what, and how well it must hold up. This article does not quote a figure. It lists the cost drivers, explains how the common pricing models shift risk, and shows how to write a scope that makes quotes comparable.
Rates and totals vary too much by country, seniority, scope and stack for any number in an article to help you. A figure quoted without a scope would mislead more than it informs, so you will not find one here. What you can do is learn which decisions move the cost, so that a quote makes sense when you see one, and so you can control the cost instead of only receiving it.
What "cost" includes
The invoice for the first build is only part of the cost. Plan for three layers, and ask any provider how each is handled:
- Build: scoping, design, development, testing, data migration and launch.
- Run: hosting, databases, third-party services you pay for by usage, monitoring and security updates.
- Change: fixes, small improvements and new features after real users arrive. Software that is used always reveals things nobody thought of in advance.
Custom software costs more up front than a subscription and has a maintenance tail. Whether the total is lower or higher than the alternative depends on your numbers, as our guide to custom software versus SaaS explains.
The cost drivers
These are the factors that move the cost of a project most. They are the same ones we use when we scope work, and none of them depends on a price list.
1. Number of workflows and kinds of user
A system built around one workflow for one kind of user is a much smaller project than one that covers several processes and several roles. Each additional workflow needs design, build and testing, and each role needs its own view of the data.
2. Permissions and audit trail
A single shared view is simple. Rules about who may see and change which records, plus a history of who changed what, take more design and testing. If you need them, say so early.
3. Data migration
Bringing existing data in from spreadsheets or an older system is often underestimated. The volume matters, but the quality matters more: duplicated, inconsistent or missing records have to be cleaned or consciously left behind. Messy source data is a common cause of extra work.
4. Integrations
Every system your software must exchange data with, such as payments, email, accounting or a CRM, adds mapping, testing and failure handling. Poor or missing APIs make an integration larger. See our page on API integrations and business automation for how we approach it.
5. Reporting and dashboards
The number and complexity of reports, exports and views the team relies on. A handful of fixed reports is a different job from flexible, user-built analysis.
6. Interface depth
Standard interface components are quicker than bespoke interaction and brand work. A customer-facing application that must be fast, accessible and polished on many devices takes more effort than an internal tool for a small team.
7. Security, hosting and compliance
Where data must live, which regulations apply, whether you need audit logs or specific access controls: these change the design. Tell any provider about them before the quote, not after.
8. How well the process is understood
If the process changes every few weeks, the software built for it will be reworked. Writing the current process down, including exceptions, is the cheapest way to reduce rework later.
9. Speed of decisions and change
Quick answers keep a project moving. Waiting on approvals, or changing scope after building has started, is possible but changes the plan and usually the cost.
10. Rollout and support
Releasing in stages spreads effort and lets you adjust. Training, documentation and support after launch are separate items and should be agreed explicitly.
| Driver | Raises the effort | Keeps it smaller | Question to answer |
|---|---|---|---|
| Workflows and users | Several processes, several roles | One workflow for one user type first | Which single workflow costs us the most time today? |
| Permissions | Fine-grained rules, audit history | A few simple roles | Who must not see or change what? |
| Data migration | Large, duplicated, inconsistent data | Clean, small, well-structured data | What must come across, and how clean is it? |
| Integrations | Many systems, weak APIs, real-time sync | Few systems, documented APIs, batch sync | Which tools must connect, and which holds the truth? |
| Reporting | Many bespoke reports, flexible analysis | A few fixed reports | Which numbers do we assemble by hand now? |
| Interface | Bespoke design, public-facing, many devices | Standard components, internal users | Who uses it, on what devices? |
| Security and compliance | Regulated data, strict access, audit | Low-sensitivity data, standard controls | What rules apply, in writing? |
| Process maturity | Process still changing | Process written down and stable | Can we describe it step by step, with exceptions? |
How pricing models shift risk
How a provider charges decides who carries the risk when estimates are wrong. None of the models is better in general. Each suits a different level of certainty.
| Model | How it works | Fits when | Watch for |
|---|---|---|---|
| Fixed price | One price for a defined scope | Scope is small, clear and unlikely to change | Change requests, thin scope documents, corners cut to hold the price |
| Time and materials | You pay for the time spent | Scope will evolve as you learn | No natural ceiling, so ask for estimates, reporting and a way to cap spend |
| Staged or milestone-based | Scope and price agreed one stage at a time | You want to learn from each release before committing further | Make sure each stage ends in something you can use and test |
| Ongoing retainer | A recurring arrangement for fixes and improvements | Software is live and keeps changing | What the retainer covers and how unused time is handled |
A staged approach is often the most practical for a business with a real but still-evolving need, because it turns one large uncertain commitment into several smaller ones. We agree the first release in writing after a scoping conversation; the structure of the arrangement is part of that conversation.
How to scope a project so quotes compare
Two providers quoting from a two-line request will quote different things. A one- or two-page brief makes quotes comparable and usually makes them better. Write down:
- The problem and the outcome. What is broken today, and what should be true when it is fixed?
- The users and their roles. Who uses it, how many, and what each may see and change.
- The workflows, in order. The steps people perform now, including exceptions, and which one should be built first.
- The data. What exists, where it lives, how clean it is and what must be migrated.
- The integrations. Which tools must connect, and which system is the source of truth for each kind of record.
- The reports. The figures the business relies on and where they come from now.
- The constraints. Where data must be hosted, regulations that apply, deadlines that are real and ones that are preferences.
- What is out of scope for the first release. Naming this is as useful as naming what is in.
- Who decides. One named person who can answer questions and approve changes.
If you cannot answer some of these, that is a finding, not a failure. A good provider will help you resolve them during scoping. Our page on custom software, web apps and internal platforms lists what we ask for to start.
How to read a quote
- Does it say what is included and what is not? A number with no scope behind it cannot be compared with anything.
- Is the work staged? Can you see and test something at the end of each stage?
- Are the assumptions written down? Data quality, number of integrations and number of roles are typical assumptions that change the price if they turn out wrong.
- What happens when scope changes? Ask how change requests are handled before you need one.
- What is not in the quote? Hosting, third-party service fees, support after launch and training are often separate.
- Who owns the code, data and accounts, and when? This should be written, not implied.
- Is the lowest number actually the cheapest? A low quote that omits testing, migration or handover moves the cost to later, where it is harder to control.
If you are also deciding who to ask, how to choose an MVP development partner has a question checklist that applies to most software projects, and agency versus freelancer versus in-house team compares the three models.
Ways to keep the cost under control
- Start with the workflow that costs the most time. A first release that fixes the worst workaround pays for the learning in the rest.
- Write down what is out. Deferring features to a second stage is cheaper than building them early and changing them later.
- Buy the commodity parts. Payments, email delivery and sometimes sign-in are rarely worth building. A hybrid of a bought core and custom parts is often the smallest project.
- Clean the data before it is migrated. Dedupe and decide what to leave behind while it is still in a spreadsheet.
- Decide quickly and in one place. One decision-maker removes more delay than any tool.
- Test with real users early. Finding a wrong assumption in a stage-one release costs far less than finding it after launch.
Compare over time, not at purchase
When you compare custom software with a subscription, use a fixed horizon, such as three to five years. For the subscription, include per-seat or usage pricing at the headcount and volume you expect, plan upgrades and the cost of workarounds. For custom, include the build, hosting, monitoring, security updates and engineering time for changes. The cheaper option at purchase is not always cheaper at year four, and sometimes the right answer is to buy.
Illustrative examples
The two scenarios below are invented to show how scope changes cost. They are not clients, describe no real engagement and contain no prices.
Next steps
Write the one-page brief, mark what is out of scope for the first release and ask each provider the same questions. If you would like to talk it through, we scope work in a conversation and agree the first release in writing before building. See custom software, web apps and internal platforms, custom CRM development or SaaS and MVP development, or read about StackEndBox first.
Frequently asked questions
- How much does custom software cost?
- It depends on scope, and nobody can give an honest figure without one. The main drivers are the number of workflows and user roles, permissions and audit needs, data migration, integrations, reporting, interface depth, security and compliance, and how well the process is understood.
- Why don't you publish prices?
- Because cost follows scope, and the same label can cover very different projects. A price list would either mislead or be so wide as to be useless. We agree the first release in writing after a scoping conversation.
- Is a fixed price cheaper than time and materials?
- Not necessarily. Fixed price transfers some estimating risk to the provider, which is reflected in the quote and often limits changes. Time and materials suits work that will evolve but needs a way to cap spend. A staged approach combines the two by pricing one stage at a time.
- What ongoing costs should I expect after launch?
- Hosting, databases, third-party services billed by usage, monitoring, security updates, and engineering time for fixes and changes. Ask any provider which of these are included and which are agreed separately.
- How can I get a rough estimate without a full specification?
- Write a one- or two-page brief covering the problem, users, workflows, data, integrations, reports and constraints, and say what the first release leaves out. A provider can then tell you what questions affect cost most, which is more useful than a guess.
- Does a CRM or an AI agent cost differently from other custom software?
- The same logic applies: cost follows scope. A CRM is driven by records, pipelines, permissions, migration and integrations. An AI agent adds how much freedom it has, its tools, evaluation and model usage. See our pages on custom CRM development and AI agent development.