New: CentriCall AI voice agents that answer, qualify, and book around the clock
Cost & Budgeting8 min read

What custom software actually costs in 2026, and why estimates double

Ranges you can plan against, the four things that actually move the number, and the specific reasons a quote doubles between kickoff and launch.

The short version
  • Most custom builds land between $60k and $400k. The spread is driven by integration count and compliance scope, not feature count.
  • Estimates double for five predictable reasons, and four of them are visible during discovery if anyone looks.
  • A quote given without access to your existing systems is a guess dressed as a number.
  • Budget 15–20% of build cost per year for maintenance. Software that nobody maintains gets replaced, which costs more than maintaining it.

Nobody publishes real numbers for this, which is why the question gets answered with “it depends.” It does depend, but on four things you can identify in a week, and the ranges are narrower than the non-answer suggests.

What follows is how we price custom software development at Centricone, what moves the number, and the specific failure modes that turn a $120k quote into a $250k invoice.

The ranges

These assume a competent team building on a modern stack, including design, testing, and a production deployment. They exclude ongoing hosting and maintenance, which are covered further down.

ScopeTypical rangeElapsed time
Internal tool. One workflow, one user group, one system to talk to$40k – $90k6 – 10 weeks
MVP. A product with real users and a payment path$80k – $180k10 – 16 weeks
SaaS platform. Multi-tenant, roles, billing, admin$150k – $400k4 – 8 months
Enterprise integration. Several systems of record, audit requirements$200k – $600k+6 – 12 months
North American delivery. Offshore-only teams quote 40–60% lower and carry a different risk profile. See the note on rates below.

The four things that actually move the number

Feature count is what clients count, and it is close to irrelevant. Screens are cheap. What follows is expensive.

1

How many systems it has to talk to

This is the single biggest driver. A self-contained app is straightforward. The same app writing to NetSuite, reading from Salesforce, and reconciling against Stripe is three integrations, each with its own auth, rate limits, sandbox, failure modes, and a partner whose API docs are wrong in at least one place. Budget two to four weeks per non-trivial integration and you will be roughly right.

2

Whether anyone audits it

HIPAA, PCI DSS, SOC 2, and GDPR do not add features. They add access control, encryption, audit logging, data retention, incident process, and evidence. Expect 20–35% on top of an equivalent unregulated build, and expect it to be cheaper designed in than retrofitted, usually by a factor of three — a fintech MVP we scoped that way put the control set in during weeks one to three rather than ten to twelve.

3

Whether something already exists

Greenfield is the cheap case, which surprises people. Replacing a live system means running both in parallel, migrating data that has fifteen years of accumulated inconsistency, and cutting over without an outage. The migration is frequently larger than the application, which is why we take these one seam at a time.

4

How many people have to agree

A founder who decides on the call is fast. Six stakeholders across three departments with a monthly steering committee is not, and the cost is real: idle engineering time while a decision is pending is still billed. This is the factor nobody puts in a quote and everybody pays for.

Why estimates double

Not because the team was cynical. Estimates double for five reasons, and four of them are findable during discovery if somebody bothers to look.

  • The integration was described, not tested. “It has an API” covers everything from a documented REST endpoint to a nightly SFTP drop of a fixed-width file. The difference is six weeks.
  • The data was worse than anyone said. Every legacy database has duplicate customers, nulls in required columns, and a free-text field somebody has been using as a status flag since 2014. This is discovered in week three, not week one.
  • Scope was fixed but requirements were not. If the contract lists deliverables and the business keeps learning, one of the two has to move. It is always the budget — which is the real argument in fixed price versus time and materials.
  • Non-functional requirements arrived late. “It also needs to handle Black Friday” and “security will need to review this” are architecture inputs. Arriving in month four, they are rework.
  • Nobody costed the last 20%. Error states, empty states, permissions, admin tooling, data export, and the migration script are not features and get left out of feature-based estimates. They are consistently a fifth of the work.
A quote produced without read access to your existing systems is a guess with a decimal point on it. The only estimates worth anything come after somebody has looked at the data.

What discovery should produce

A paid discovery of one to three weeks costs $8k–$25k and should end with artefacts you own outright, usable by another firm if you decide not to proceed. If a discovery ends in a sales deck rather than these, it was a sales process:

Deliverables worth paying for
  • A ticket-level backlog with estimates per item, not a lump sum
  • An architecture diagram naming every system and every integration
  • A written list of assumptions, each one a thing that changes the price if wrong
  • The migration and cutover plan, if something already exists
  • A fixed number, with the conditions under which it changes stated plainly

The cost after launch

Budget 15–20% of build cost per year. On a $150k build that is $22k–$30k annually, covering dependency and security patching, cloud spend, monitoring, bug fixes, and small changes.

This is the line most often cut, and cutting it is how three-year-old software becomes a rewrite. Dependencies go end-of-life whether or not you have budget for them. The rewrite costs more than the maintenance would have, and it costs it all at once — which is the case for buying maintenance and support as a line rather than a reaction.

15–20%

of build cost, per year, to keep software supported

3×

typical premium for retrofitting compliance versus designing it in

Does it cost more in California than in Georgia?

Yes, and less than people expect. Rate differences between US metros are real but they are compressed by remote delivery: a firm in Atlanta and a firm in San Francisco are often bidding for the same engineers. The gap that survives is roughly 20–35% at the top of the market, not the 2x the geography implies.

Where the team sitsBlended day rateWhat actually drives the difference
Bay Area / New York$1,200–$1,900Local salary floor set by competition with product companies for the same engineers
Atlanta / Dallas / Denver$900–$1,400Deep enterprise talent pool without the product-company salary premium
Nearshore (Latin America)$450–$750Timezone overlap intact; the rate gap holds if communication does
Offshore (South and Southeast Asia)$250–$450Lowest rate, highest variance in total delivered cost
Blended day rates across a mixed team, 2026. Rate is the least predictive input into total cost — see the offshore question below.

Enterprise costs are a different question

Searches for enterprise custom software cost are usually asking something the general ranges do not answer, because in an enterprise the software is rarely the expensive part. The integration surface is.

  • $200k–$600k is the common band for a departmental system with three to six real integrations, and the integrations are most of it
  • Procurement and security review routinely add six to twelve weeks before a line of code is written, and that time is billed by someone
  • Access provisioning is the most reliably underestimated line item — an engineer who cannot reach a system is a paid engineer who cannot start
  • Change control in an audited environment means every release carries process cost, which compounds across a long engagement
  • Decommissioning the thing you are replacing is almost never in the original number, and it is not optional

The practical consequence: in enterprise the discovery phase is worth more, not less, because it is the only place the integration surface gets measured before it is priced. See enterprise IT staff augmentation where the constraint is capacity rather than scope.

Why costs spike after a vendor migration

A specific and common failure, worth separating from ordinary overrun. Costs rise after switching vendors for reasons that have little to do with the new vendor rate card.

1

The new team is paying down knowledge, not building

Six to ten weeks of a takeover is reconstructing decisions nobody wrote down. That is real work, it produces no visible feature, and it was rarely quoted.

2

The previous scope was never actually complete

Work the outgoing vendor had absorbed quietly — a manual step someone ran monthly, a patch applied by hand — becomes a line item the moment a new team has to formalise it.

3

Both vendors are billing during the overlap

A safe transition needs a period where the old team is still reachable. Cutting it to save money is how a migration becomes an outage.

4

Deferred maintenance comes due at once

End-of-life dependencies and expired certificates do not appear on a handover document. They appear in the first month.

How to read a quote

Two firms quoting $95k and $180k for the same brief are not pricing the same work. Before comparing, find out what each has assumed, and whether either has actually looked.

  1. 1Which integrations are in scope, and has anyone tested credentials against them?
  2. 2Who writes the migration script, and against what volume of real data?
  3. 3Is QA a line item or a hope? Is there a written definition of done?
  4. 4What happens to the price when an assumption turns out wrong: a change order, or absorbed?
  5. 5Who owns the code and the cloud account on day one, and on the day you leave?

Working through this on a real project?

Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.

Common questions

Most custom builds land between $60,000 and $400,000. An internal tool is typically $40k–$90k, an MVP $80k–$180k, a multi-tenant SaaS platform $150k–$400k, and an enterprise integration $200k–$600k or more. The spread is driven by how many systems the software must integrate with and whether it falls under a compliance regime, not by how many screens it has.
Five recurring reasons: an integration was described rather than tested, the legacy data was worse than anyone stated, scope was fixed while requirements kept changing, non-functional requirements like peak load or security review arrived late, and the final 20%, covering error states, permissions, admin tooling, and migration scripts, was never costed because it is not a feature. Four of the five are visible during a proper discovery.
Yes, if it produces artefacts you own. A one-to-three-week paid discovery costs $8,000–$25,000 and should end with a ticket-level backlog, an architecture diagram, a written assumptions list, a migration plan, and a fixed number. If you can take those documents to another firm and get a comparable quote, the discovery was real. If it ends in a proposal deck, it was a sales process.
Budget 15–20% of the original build cost annually. That covers dependency and security patching, cloud infrastructure, monitoring, bug fixes, and small enhancements. Skipping it is the most common route to an expensive rewrite: dependencies reach end-of-life regardless of budget, and a rewrite costs more than the maintenance would have, and all at once.
Expect a blended day rate of $1,200–$1,900 in the Bay Area and Los Angeles against $900–$1,400 in metros like Atlanta, Dallas, and Denver — a gap of roughly 20–35% rather than the multiple the geography suggests, because remote delivery means both are often bidding for the same engineers. The project drivers do not change with location: integration count, compliance scope, and data quality set the total, and a rate advantage does not survive a specification nobody tested.
Most US custom builds land between $60,000 and $400,000, at blended day rates from $900 to $1,900 depending on the metro. An internal tool is typically $40k–$90k, an MVP $80k–$180k, a multi-tenant SaaS platform $150k–$400k, and an enterprise integration $200k–$600k or more. US rates carry a premium over nearshore and offshore, and whether that premium is worth paying depends on how many attempts the work would otherwise take.
Commonly $200,000 to $600,000 for a departmental system with three to six genuine integrations, and above that where the integration surface is larger. In an enterprise the application is rarely the expensive part — the integrations, security review, access provisioning, change control, and decommissioning the system being replaced usually exceed it. Those costs are predictable, but only if discovery measures the integration surface before anyone prices it.
Usually four things at once: the new team spends six to ten weeks reconstructing undocumented decisions, work the previous vendor absorbed quietly becomes a formal line item, both vendors bill during a safe overlap period, and deferred maintenance the handover never mentioned comes due immediately. The comparison that makes it look like a spike — new invoice against old invoice — is generally not comparing the same scope.
The day rate is lower, $250 to $450 versus $900 to $1,400 in North America, but rate is the least important variable in total cost. What matters is how many attempts a team needs. Rework, timezone latency on decisions, and specification churn routinely erase the rate advantage. Compare total delivered cost and the quality of the discovery, not the hourly figure.
Normalise what is actually included before comparing numbers. Quotes differ most in whether they cover discovery, testing, deployment, project management, and post-launch support — and a cheaper quote that excludes three of those is not cheaper. Ask each supplier to price the same explicit scope.
The assumptions it depends on, what is excluded, the confidence range, and what would change it. An estimate presented as a single number with no stated assumptions is not an estimate; it is a negotiating position, and it will move the first time reality contradicts something nobody wrote down.
Because it is made when least is known, which is unavoidable rather than negligent. The useful question is whether the supplier revises openly as information arrives, or defends the original number until the overrun is undeniable. A forecast that updates is worth more than one that was confident early.