Why do software development estimates vary so much between vendors?

Usually because they are pricing different things. One quote may include testing, a deployment pipeline, data migration and a support period, while another covers only the screens. Some quotes carry a large buffer for unknowns and some carry none. Before comparing totals, line the quotes up against the same scope and assumptions. Most of the gap tends to disappear, or it reveals exactly what the cheaper quote left out.

Is a fixed price cheaper than time and material?

Not necessarily. A fixed price gives you budget certainty, but the vendor carries the risk of the unknown, so a sensible fixed quote includes a buffer for it. Time and material passes that risk to you and you pay only for the work done, which can work out cheaper when the scope is reasonably clear but still being refined. The right choice depends on how settled your scope is, not on which model looks lower on paper.

How much should I budget for software maintenance after launch?

Treat maintenance as a recurring line item from day one rather than a surprise. It covers security patches, framework and library upgrades, hosting, monitoring, bug fixes and the small changes users ask for. The amount depends on how many integrations the system has, how often its dependencies change and how actively you want to keep developing it. Ask any vendor to estimate the run cost alongside the build cost.

How can I reduce the cost to build an app without hurting quality?

Cut scope, not engineering. Launch with the smallest set of features that proves the idea to real users, deliver in phases, and use existing services for commodity parts like authentication, payments and email. Keep the things that protect you later: automated tests on the rules that matter, a repeatable deployment, sensible security and basic documentation. Skipping those makes the first release slightly cheaper and every release after it more expensive.

Custom Software Development Cost: What Drives It

Q: How much does custom software cost?

It depends on effort, not on a category. Cost is roughly the number of person-weeks the work needs multiplied by the team's rate, plus hosting, third-party services and maintenance after launch. A small internal tool with one integration and a complex platform with payments, migrations and compliance rules can both be called "an app" and differ in cost many times over. The only reliable number comes from an estimate built on a written scope.

Custom software development cost is set by effort, not by a price list. The honest formula is the number of person-weeks the work needs, multiplied by the team's rate, plus what it costs to host, support and change the software once it is live. What moves that number is scope, integrations, data, compliance, team shape, the quality bar you need and maintenance after launch. Until those are written down, any figure you are given is a guess.

That answer frustrates people, because "how much does custom software cost?" feels like it should have a number attached. It does. It just has to be your number, worked out from your project, rather than an average across thousands of projects that look nothing like yours.

So this post does not contain a price table. It explains what actually drives the cost, how to read an estimate when you get one, a simple way to sanity-check a quote with your own figures, and where you can save money without creating a bigger bill later.

Cost is effort times rate, plus the cost of running it

Every software development estimate, however it is presented, is built from three parts:

Effort. How many people, for how long. A team of three working for four months is twelve person-months. This is where almost all of the variation lives.
Rate. What each person-month costs. Rates vary with seniority, location and the type of engagement, but for any single vendor they are fairly stable. How that rate is billed depends on the engagement model, which we compare in fixed price vs time and material vs a dedicated team.
Run cost. Hosting, third-party services, licences, monitoring, and the ongoing engineering time to keep the software secure and current.

Software development pricing that only shows the first two is incomplete. Software is not a purchase you make once, like a printer. It is closer to a building: the construction cost is the big number, but the running cost is what you live with.

What actually drives custom software development cost

When two projects that sound similar end up with very different estimates, the difference almost always comes from the factors below. None of them are visible on a screen mockup, which is why mockups are such a poor guide to cost.

Scope: screens are cheap, rules are expensive

A screen that lists orders is quick to build. The rules behind it are not: who can see which orders, what happens when an order is refunded halfway through fulfilment, how discounts stack, what the system does when stock runs out between checkout and payment. Business rules, edge cases and permissions are where effort accumulates. Ten simple screens can cost less than two screens with complicated logic behind them.

Integrations

Every external system you connect to adds work: a payment provider, an accounting package, a CRM, a warehouse system, a government API. Each one needs authentication, error handling, retries, testing against a sandbox, and a plan for what happens when the other side is down or changes its behaviour. Well-documented, modern APIs are relatively predictable. Older systems with partial documentation, or no API at all, are not.

Data and migration

If the new system replaces an old one, the existing data has to come with it. Migration means mapping old fields to new ones, cleaning records that never matched the rules, deciding what to do with duplicates, and rehearsing the move so that go-live is not the first attempt. It is routinely underestimated because it is invisible until it goes wrong.

Compliance and security

Handling health records, payments, children's data or personal data in regulated markets adds requirements: access control, audit trails, encryption, data retention rules, and sometimes external review. These are not optional extras, and they are much cheaper to design in from the first sprint than to retrofit after launch.

Team shape

A project that needs a backend engineer, a mobile engineer, a designer and a QA engineer costs more per month than one that needs a single full-stack developer, but it may finish sooner. Seniority matters too. A senior engineer costs more per hour and often costs less per feature, because they make fewer decisions that have to be undone.

Quality bar

An internal tool used by five people in one office has a different quality bar from a customer-facing app that handles payments. Uptime targets, performance under load, accessibility, browser and device coverage, and the depth of automated testing all scale effort. Be clear about which one you are building.

Maintenance after launch

Frameworks release security patches, operating systems update, third-party APIs change, and users ask for improvements. Software that is not maintained gets harder and more expensive to change over time. That ongoing cost is real and belongs in the budget, which is why we cover it separately as support and maintenance rather than pretending launch is the finish line.

The factors that affect software cost, at a glance

Factor	Pushes cost up when	Keeps cost down when
Scope	Many business rules, roles and edge cases	A narrow first release with clear rules
Integrations	Legacy systems, poor documentation, no sandbox	Modern, well-documented APIs
Data	Large, messy migration from an old system	A fresh start, or clean exportable data
Compliance	Regulated data, audit and retention needs	No sensitive or regulated data
Team shape	Many specialist roles needed at once	One small cross-functional team
Quality bar	Public-facing, payments, high uptime	Internal use, tolerant of short downtime
After launch	Many dependencies, active roadmap	Stable scope, few moving parts

How to read a software development estimate

A good estimate is not just a total. It is a description of what the vendor thinks you are buying, with the number attached. When one lands on your desk, look for these things before you look at the price.

A written scope. Features, roles and integrations listed in plain language. If you cannot tell from the document what will and will not be built, the number is not anchored to anything.
Assumptions. Every estimate rests on them: "the payment provider has a working sandbox", "the client supplies content", "existing data is exportable as CSV". Assumptions are where surprises come from, so you want them stated, not implied.
What is excluded. Hosting, app store fees, third-party licences, content, data migration and post-launch support are the usual suspects.
A range or a confidence level. Early estimates carry uncertainty. A single precise figure for a loosely defined project should make you more cautious, not less.
The non-feature work. Testing, code review, a deployment pipeline, environments, documentation and handover. If none of it appears, either it is hidden in the feature lines or it is not being done.
Milestones. A breakdown into phases with something you can see and use at the end of each.

Comparing two quotes

When quotes differ widely, resist the urge to compare totals. Put them side by side against the same list: scope, assumptions, exclusions, testing approach, team composition, and what happens after launch. Most of the gap usually turns out to be one quote including things the other left out. If a gap remains after that, ask each vendor to explain the parts you do not understand. How they answer tells you a lot about how the project would go.

Sanity-check a quote with your own numbers

You do not need to be an engineer to check whether an estimate is in a believable range. You need a few figures from the quote and some simple arithmetic. Here is a worksheet you can fill in.

Team size. How many people will work on it? Count part-time roles as fractions.
Duration. How many months, from start to launch?
Person-months. Multiply the two. This is the effort the vendor is really quoting.
Implied monthly rate. Divide the build price by person-months. Does it match what the vendor says its people cost?
Effort per feature. Divide person-months by the number of major features in the scope. Does any feature look implausibly cheap or expensive next to the others?
Run cost. Add the yearly hosting, services and maintenance estimate. If the quote does not include one, ask for it.

A worked example, with made-up figures. Say a quote proposes three people for four months. That is twelve person-months. If the scope lists six major features, that is two person-months each, on average. Now look at the list. If one of those features is "migrate ten years of customer records from the old system" and another is "contact form", the average is hiding something, and it is fair to ask how the effort is really split.

This check will not tell you the right price. It will tell you whether the quote is internally consistent, and it gives you specific, reasonable questions to ask. A vendor who has thought the work through will be able to answer them.

If an estimate seems low for work that touches a lot of existing systems, it is worth reading why small software changes take so long. The visible feature is rarely where the time goes.

How to reduce cost without cutting the wrong corners

There are good ways and bad ways to make software cheaper. The good ways reduce what you build. The bad ways reduce how well it is built.

Good ways to save

Start with a minimum viable product. Pick the smallest set of features that proves the idea with real users, launch it, and let usage decide what comes next. This is how we approach MVP and SaaS product development: a first release that is small, but built on a foundation you can keep extending.
Deliver in phases. Split the project into releases, each useful on its own. You pay for the first phase, learn from it, and fund the next one with better information.
Use existing services for commodity parts. Authentication, payments, email delivery, file storage and search are solved problems. Paying for a well-run service is usually cheaper than building and maintaining your own.
Decide quickly. Waiting on decisions costs money, because the team either stalls or guesses. A single person on your side with authority to say yes or no is one of the cheapest efficiency gains available.
Bring your data early. If migration is in scope, provide sample exports at the start. Problems found in week one are cheap. Problems found the week before launch are not.

Corners not to cut

Automated tests on the rules that matter. Not total coverage, but the logic that would cost you money if it broke.
A repeatable deployment. If releasing depends on one person's laptop, every release is a risk.
Security basics. Access control on every request, secrets kept out of the code, dependencies kept current.
Documentation and handover. You should own the code and understand what you own, whoever maintains it next.

Skipping these makes the first release a little cheaper. It makes every release after it more expensive, and that is the bill that keeps arriving.

What to bring to a first conversation

You will get a better estimate, faster, if you can describe a few things in plain language: what the software must do and for whom, which systems it has to connect to, what data already exists, any regulations that apply, and the date or budget you are working towards. Rough answers are fine. "We are not sure yet" is a useful answer too, because it tells the engineer where the uncertainty is.

If you want a number for your own project, book a free 30-minute discovery call. A senior engineer will talk it through with you, and we send a written approach, timeline and estimate within two business days.

What Custom Software Really Costs, and How to Check a Quote