"How much will it cost?" is the first question almost everyone asks about custom software. It is a fair question. The frustrating answer is that it depends, but it depends on things you can understand and control. Getting the estimate right matters. Research by McKinsey and the University of Oxford on more than 5,400 IT projects found that large ones ran 45% over budget on average and delivered 56% less value than predicted.
The true cost of software
- 01
Build
Design, code and test. What most quotes show.
- 02
Run
Hosting and services. Every month.
- 03
Maintain
Updates and fixes. Every year.
- 04
Improve
Changes users ask for. A sign it is working.
First, should it be custom at all?
Before talking price, check whether you need custom software. If an off the shelf tool does eighty percent of what you need, it is often smarter to adapt your process slightly and pay a subscription.
Custom software makes sense when:
- Your process is a genuine advantage and generic tools would flatten it.
- You are paying for several tools that do not talk to each other, and staff copy data between them all day.
- Subscription costs grow with every user, and you have a lot of users.
- No existing product handles your local rules, languages, payment methods or connectivity conditions.
What drives the cost
Scope. The number of features, screens and workflows. This is always the biggest factor.
Complexity of the logic. A form that saves data is simple. A system that calculates pricing across regions, tax rules and discounts is not, even if it has fewer screens.
Integrations. Every connection to another system, whether accounting, payments, a CRM, a government portal or old internal software, adds work. Older systems with poor documentation add the most.
Users and permissions. Different roles that see different things, approve different steps and need audit trails.
Platforms. Web only, mobile only, or both.
Performance and scale. Software for fifty internal users is a different job from software for fifty thousand customers.
Security and compliance. Health, finance and personal data all raise the bar, as they should. The OWASP Top Ten is a good reference for the common risks any serious build should address.
The costs people forget
The build is only part of the bill. Plan for these too:
- Hosting and services. Servers, storage, email and SMS, and third party APIs all have running costs.
- Maintenance. Software needs updates, security patches and bug fixes long after launch.
- Changes. Once people use the system, they will want improvements. That is a good sign, but it needs budget.
- Training and rollout. Getting your team to actually use the new system takes time and effort. How pricing models work Model How you pay Works best when Watch out for
Many projects combine them: a fixed price discovery phase, then time and materials or a dedicated team for the build.
Ways to reduce the cost without cutting quality
- Start with a small first release and grow it based on real use.
- Use proven services for login, payments, messaging and storage instead of building them.
- Replace your messiest spreadsheet or manual step first, where the payoff is most visible.
- Keep one decision maker on your side so the team is not waiting on approvals.
- Invest in a short discovery phase so estimates are based on facts, not guesses.
How to get a quote you can trust
Give the team as much detail as you can: who will use it, what they need to do, which systems it must connect to, and what success looks like. Then look for a quote that breaks the work down feature by feature. Vague quotes hide risk. Detailed ones show the team has thought it through.
A worked example of how scope changes the price
Picture a company that wants software to manage field service visits. Version A lets office staff schedule visits and lets technicians mark them complete on a phone friendly web page. Version B adds customer self booking, automatic invoicing through the accounting system, a native mobile app with offline mode, and detailed reports for managers. Both solve the same business problem. Version B will cost far more, not because any one feature is huge, but because each addition brings new screens, new integrations, new user types and more testing. Starting with Version A and adding pieces as the business proves the need is usually the smarter path.