What Custom Software Actually Costs in 2026 — A Line-by-Line Breakdown

Ask five agencies to quote the same brief and you will get numbers that differ by a factor of five. That spread is almost never about how good the developers are. It is about what each quote silently includes, what it silently excludes, and how much risk the agency is pricing in because your brief left too much unsaid.

This is the breakdown we use internally. It is not a price list — your number depends on your scope — but it will let you read someone else's quote and know which line they left out.

The five things you are actually paying for

Every custom software budget decomposes into the same five buckets, whether or not the proposal says so:

• Discovery and architecture — deciding what gets built and how the data is shaped. Typically 8–15% of the total.
• Product engineering — the screens, the API, the business logic. Usually 50–60%.
• Infrastructure and delivery — environments, pipelines, monitoring, deployment. 10–15%.
• Quality — automated tests, manual passes, accessibility, security review. 10–15%.
• Handover and support — documentation, runbooks, the bug-fix window after launch. 5–10%.

A quote that is dramatically cheaper than the others has usually deleted buckets three, four and five. Those costs do not disappear. They move to you, six months later, usually at a worse time.

Discovery is the cheapest money you will spend

A week or two of discovery on a three-month build feels like overhead. It is the opposite. The three decisions made there — how tenants are isolated, who can see what, and how billing works — are the ones you cannot cheaply reverse once there is production data behind them.

We have written about this at length in how we scope a SaaS MVP that ships in 8–12 weeks: the projects that slip are almost never slowed by engineering, they are slowed by a decision nobody would make. If an agency offers to skip discovery to save you money, they are offering to move the cost to a point where it is ten times larger.

What moves the number most

In rough order of impact:

• Integrations. Each third-party system you must talk to adds cost that scales with how bad its API is, not with how important it is to you. A payment gateway with good docs is a week. An ERP with a SOAP endpoint and no sandbox is a month.
• Architecture choices made for fashion. Going headless on a store that did not need it can double a commerce budget and the ongoing bill with it.
• Roles and permissions. "Admins and users" is cheap. Five roles with per-field visibility rules is a subsystem.
• Offline and real-time. Both force a different data model. Decide before the build, not after — see native vs cross-platform for how this plays out on mobile.
• Compliance. GDPR, PCI-DSS or SOC 2 readiness is not a feature you bolt on. It changes logging, retention, access control and your deployment process.
• Data migration. Moving ten years of messy records off an old system routinely costs more than the feature that replaces it.

The costs most quotes leave out

Four lines are missing from most proposals, and all four are real:

• Cloud spend. Small at launch, but it is a monthly bill forever. Ask for an estimate at your expected year-one load, not at zero users.
• Third-party subscriptions. Email delivery, error tracking, maps, SMS, storage. Individually trivial, collectively a real line item.
• The post-launch year. Bug fixes, dependency updates, security patches. Budget 15–20% of the build cost annually. If nobody does this work, you are not saving money — you are accruing a rebuild.
• Your own team's time. Someone on your side has to answer questions, review demos and make decisions. That is real cost, and projects where nobody was allocated to it are the ones that drift.

How to compare two quotes honestly

Put them side by side and ask four questions. Who owns the code and the cloud accounts? What happens to bugs found in month two? Which of the five buckets above is not in this number? And what, specifically, would make this estimate wrong?

The fourth question is the one that separates a considered estimate from a hopeful one. An agency that has thought about your project can name its own risks. One that cannot has priced a guess. We go further into this in the ten questions to ask before you sign and in fixed price vs time and materials.

A realistic shape for a first build

For a business application with a real user base — think 30–60 screens, a few roles, two or three integrations, and a payment flow — a competent team is looking at three to five months and a number that reflects that. Anything promising the same scope in six weeks is either cutting the quality and infrastructure buckets or has not understood the brief.

Our own clinic management system and restaurant POS case studies show what that shape looks like in practice, including what we deliberately left out of version one.

Where to go next

If you are early and still deciding how to staff the work, offshore vs nearshore vs in-house compares the three models on cost and control. If you already know what you want built, how to write a software RFP that gets useful quotes will get you numbers you can actually compare.

Or send us the brief. We will come back with a scope, a fixed estimate, and an honest note about which parts we think you should cut — start here, or read about how our consulting engagements work.