You send the same project description to three software companies and get back three numbers that barely seem to describe the same project. Which one is right?
Usually none of them is wrong. They are pricing different things. This guide explains what drives custom software development cost, why vendors land so far apart, and how to read an estimate closely enough to compare quotes fairly. It contains no price tables or hourly rates, because a number without your scope behind it would not help you budget.
Quick answer
The cost of custom software is mostly effort: the number of people, their seniority, and how long they work. Effort is driven by ten things: scope and business rules, user roles, integrations, data migration, design, platforms, non-functional requirements (security, performance, accessibility, uptime), team seniority, quality work, and project management.
Estimates differ between vendors mainly because each vendor fills the gaps in your brief with different assumptions, and includes or leaves out different items. To compare quotes, line them up item by item, read the assumptions and exclusions before the total, and treat a range with stated contingency as more honest than a single precise figure.
The cost drivers, and what makes each one expensive
What you are building
Scope and business rules. Screens are a poor measure of size. Rules are a better one. A form that saves a record is cheap. The same form becomes expensive when the price depends on the customer type, the approval depends on the amount, and three exceptions apply to one region. Every rule has to be discovered, built, tested and later maintained.
User roles and permissions. Each role is, in effect, a different product: a customer, a staff member, a manager and an administrator see different screens, can do different things and need separate testing. Cost rises further when permissions depend on data, for example "a regional manager can approve orders only for their own region."
Integrations. Connecting to a payment provider, a CRM, an accounting package or an older internal system is rarely a matter of "calling the API." The cost depends on how good the other system's documentation is, whether a test environment exists, how it handles errors and rate limits, and what your software should do when the other system is unavailable.
Data migration. If you are replacing spreadsheets or an old system, someone has to map old fields to new ones, clean duplicates and incomplete records, run trial migrations, and plan the cut-over. This is the driver most often missing from quotes, and the cost depends far more on the quality of your existing data than on its volume.
How it looks and where it runs
Design. There is a wide gap between applying a standard component library to your screens and running user research, building a custom design system and testing prototypes with real users. An internal admin tool rarely needs the second; a consumer product often does.
Platforms. A web application, an iOS app and an Android app are three front ends that share a backend. Cross-platform frameworks reduce duplicated effort but do not remove it. We compare the options in native vs Flutter vs React Native. Offline support, old browser or device support, and multiple languages each add work on every screen.
How well it must work
Non-functional requirements describe qualities rather than features, and they are the main reason two quotes for "the same app" differ. The usual ones are:
- Security. Saying "it must be secure" cannot be priced. A named standard can. The OWASP Application Security Verification Standard, for example, provides a list of requirements for secure development and a basis for testing web application security controls.
- Accessibility. WCAG 2.2 is the current version of the W3C guidelines. Meeting a stated conformance level affects design, development and testing. Whether accessibility is a legal obligation for your product depends on your sector and on whether you operate in the US, the UK or both, so ask a lawyer; this article is not legal advice.
- Performance and availability. Software for a small internal team and software for a public launch with unpredictable traffic need different architecture and testing. Uptime targets, recovery time and audit trails cost effort to build and to prove.
- Compliance. Handling health, payment or personal data brings obligations that differ between the US and UK. A vendor needs to know which apply before estimating.
Who builds it and how
Team seniority. Senior engineers cost more per hour and often less per finished feature, because they make fewer wrong turns and leave less to redo. A quote built on a junior-heavy team can look cheaper in hours and cost more in total.
Quality work. Automated tests, code review, QA across devices, and documentation are effort you cannot see in a demo. They are also the easiest items to remove from a quote to win on price, and the hardest to add once the code exists.
Project management. Someone has to plan the work, run the meetings, chase decisions, track risks and report progress. If no line covers this, it is either hidden inside the development hours or expected to come from you.
Summary table: questions that reveal the size of each driver
| Driver | Question to answer in your brief | What pushes cost up |
|---|---|---|
| Scope and rules | What are the main workflows and their exceptions? | Many conditional rules, approvals, calculations |
| User roles | Who uses it, and what may each role see and do? | Permissions that depend on the data itself |
| Integrations | Which systems must it exchange data with, and in which direction? | Poor documentation, no test environment, two-way sync |
| Data migration | What data moves over, and how clean is it? | Duplicates, inconsistent formats, several source systems |
| Design | Standard components or a custom design system? | User research, custom branding, animation |
| Platforms | Web, iOS, Android, offline, languages? | Each added platform, offline mode, old devices |
| Non-functional | Which security, accessibility, uptime and compliance targets apply? | Named standards that must be evidenced, high uptime |
| Team, quality and management | Who decides on your side, and how many stakeholders are involved? | Slow decisions, broad device coverage, heavy reporting |
Why estimates from different vendors differ so much
A large spread between quotes is normal, and it usually tells you about the brief as much as about the vendors. The common causes are:
- Different assumptions. Where your brief is silent, each vendor guesses. One assumes email-and-password login; another assumes single sign-on with your company directory. One assumes you supply clean data; another prices the cleanup.
- Different inclusions. Design, QA, project management, deployment, app store submission and post-launch support may be included, excluded or simply not mentioned.
- Different quality levels. A quote with automated tests and code review is pricing a different product from one without.
- Different attitudes to risk. Some vendors price the likely case and plan to raise change requests. Others include contingency up front. The second quote looks higher and may end lower.
- Optimism. People estimating projects tend to be over-optimistic. The UK Treasury's guidance on optimism bias was written for public-sector project appraisal, not for software quotes, but its point applies: it recommends explicit adjustments to cost and duration estimates based on data from past or similar projects.
An illustrative scenario (not a client case study). A training company asks for a booking portal. Quote A is noticeably lower than Quote B. Read side by side, Quote A assumes the client provides finished designs, excludes moving the existing customer list, covers web only, and offers no support after launch. Quote B includes design, migration of the customer list, a mobile-friendly build tested on a stated list of devices, and a support period. The two vendors are not far apart on price for the same work. They were never quoting the same work.
How to read an estimate line by line
Start with the assumptions and exclusions, not the total. Then check that each of the following has a visible line or a clear statement of who is responsible.
| Part of the estimate | What a good one shows | Warning sign |
|---|---|---|
| Scope breakdown | Features or modules listed with effort against each | One lump sum for "development" |
| Assumptions | A written list you can confirm or correct | None stated |
| Exclusions | Explicit: for example content, licenses, hosting fees, third-party charges | Nothing excluded, which usually means nothing was considered |
| Integrations | Each system named, with what is exchanged | "API integration" as one line |
| Data migration | Sources, cleanup responsibility, trial runs | Absent when you are replacing a system |
| Testing and QA | Types of testing, devices and browsers covered | No QA line, or QA at the very end only |
| Team and project management | Roles, seniority and a reporting rhythm | Hours with no roles |
| Deployment and launch | Environments, release steps, store submission if mobile | Estimate stops at "development complete" |
| After launch | Warranty or bug-fix period, support terms, running costs flagged | Silence on anything after go-live |
| Contingency | Shown separately, with what it covers | Hidden or missing |
To compare quotes fairly, build one sheet with these rows down the side and one column per vendor. Where a cell is empty, ask the vendor in writing. Then send all vendors the same clarified assumptions and ask them to requote. The spread usually narrows, and the differences that remain are real differences in approach, team or price.
Also separate the build cost from running costs. Hosting, third-party subscriptions, app store accounts, maintenance and future changes are not part of most build estimates, but they are part of what you will pay.
Estimate ranges and contingency
An estimate is a forecast made with incomplete information. Early on, before anyone has looked at your data or the systems you integrate with, an honest forecast is a range. As the unknowns are investigated, the range narrows.
That is the purpose of a discovery phase. The UK government's service manual, written for public services but sound advice generally, puts it simply: before you commit to building a service, you need to understand the problem that needs to be solved. A short paid discovery typically produces a specification, a prioritized feature list and a much tighter estimate than a quote written from a two-page brief.
Contingency is an allowance for the things that cannot be known yet. It is not padding, provided it is visible. Ask each vendor:
- Is contingency included, and is it shown separately?
- Which risks is it meant to cover?
- Who approves spending it, and what happens to the unused part?
- What would make the estimate change, and how will you tell me?
Fixed price vs time and materials
The pricing model does not change how much work the project needs. It changes who carries the risk if the estimate is wrong.
- Fixed price: the vendor carries the risk of overrun on the agreed scope, so the price normally includes a risk allowance, and every change goes through a change request. It suits small, well-specified work.
- Time and materials: you pay for the work actually done, so you carry the overrun risk and keep the flexibility. It needs a budget cap and active prioritization on your side.
Many projects combine the two: paid discovery, then a fixed price or capped budget per phase. We cover engagement models, contracts and payment milestones in detail in our guide to outsourcing software development from the US or UK.
How to reduce cost without cutting quality
The safe way to spend less is to build less, or to remove uncertainty. The unsafe way is to remove testing, review or senior oversight. Practical options:
- Cut scope by priority. Sort features into must-have for launch and later. Release the first group, learn from real use, then decide on the rest.
- Reduce roles and exceptions. Ask whether every role and every special case is needed on day one. Handling a rare exception manually for the first months is often cheaper than automating it.
- Buy the commodity parts. Use established services for payments, authentication, email and similar functions, and spend custom effort on what is specific to your business.
- Use standard design and fewer platforms at first. A component library for admin screens and a responsive web application may be enough to prove the product before funding custom design and native apps.
- Clean your data yourself. Removing duplicates and fixing formats before migration is work your own team often does best.
- Prepare a clear brief. Written workflows, roles, sample data and access to the systems to be integrated remove assumptions, and with them the risk allowance vendors add.
- Decide quickly. One empowered product owner on your side who answers questions promptly saves more paid waiting time than most technical choices.
What not to cut: automated tests on core workflows, code review, security basics, backups, and the documentation needed for another team to take over. Savings here reappear later as defects, slow changes and dependence on one vendor.
For technical readers
- Ask how the estimate was produced: a work breakdown with per-item effort, comparison with similar past projects, or a mix. Ask for best, likely and worst cases on the riskiest items.
- Check whether non-functional requirements are stated as testable targets (response times under a defined load, recovery time and recovery point objectives, a WCAG conformance level, a named security verification standard) or as adjectives.
- Look for environment and pipeline work: staging, continuous integration, automated deployment, monitoring and logging. These are easy to omit from a quote.
- For integrations and migration, ask whether the vendor has budgeted a technical spike against each third-party system and a rehearsal on a copy of production data.
Frequently asked questions
Why can't a vendor give me an exact price up front?
Because the price depends on details that are not yet known: the exact rules, the state of your data, and how the systems you integrate with behave. A vendor can give a range early and a firmer figure after a discovery phase. An exact figure from a short brief is either padded for risk or likely to grow through change requests.
Is the cheapest quote always a bad choice?
No. It is a reason to check what it includes. If the lowest quote covers the same scope, quality work and support as the others, it may simply reflect a more efficient team or lower operating costs. If it is lower because design, testing, migration or project management are missing, it is not a like-for-like comparison.
How much contingency should an estimate include?
There is no universal figure, and we would be inventing one if we gave it. Contingency should reflect how much is still unknown: more for a project with unexplored integrations and messy data, less after a thorough discovery. What matters is that it is visible, tied to named risks, and controlled by agreed rules.
Should I share my budget with vendors?
Sharing a budget range usually leads to more useful proposals, because the vendor can suggest what scope fits rather than guessing. The risk is that proposals drift up to the top of the range. You can limit this by asking each vendor to show what they would deliver at the lower and the upper end, and by comparing the line items rather than the totals.
Conclusion and next step
Custom software development cost is the sum of decisions: how much the software does, for whom, connected to what, to which standard, and built by which team. Quotes differ because vendors make those decisions differently when the brief leaves them open. Reading an estimate well means reading its assumptions, exclusions and contingency before its total, and putting every quote on the same grid.
A practical next step is to write down your answers to the questions in the cost driver table above and send the same document to every vendor you are considering. If you would like an estimate for your own project with the assumptions set out in this way, you can request a quote from Entrant Technologies, or see the kinds of work we take on at our services page.
