How Much Does Custom Software Development Cost? A 2026 Pricing Guide

"It depends" is a true answer and a useless one. Business owners asking about custom software pricing deserve actual numbers, so this guide gives you three concrete tiers, the specific factors that move a project from one tier to the next, an honest look at what a quote does and does not include, and the red flags that separate a lean bid from a dangerous one.

The three tiers, with real ranges

Every custom build we scope falls roughly into one of three bands. These ranges assume a US-based agency team; they hold reasonably well across most English-speaking markets.

Internal tool, $10,000 to $30,000. A single-purpose application used by one team: an inventory tracker, a scheduling board, an internal approval workflow. Usually one or two user roles, minimal integration, a straightforward data model. Timeline runs 6 to 10 weeks.

Departmental system, $30,000 to $100,000. Multiple user roles, real reporting needs, two to four integrations with tools you already run (accounting software, a CRM, a shipping API), and a data model that has to survive contact with messy real-world edge cases. Timeline runs 3 to 6 months.

Business-critical platform, $100,000 to $500,000 or more. The system your operation actually runs on. Customer-facing components, compliance requirements, high concurrency, multiple integrations that all have to stay in sync, and a data migration from an existing system that cannot go wrong. Timeline runs 6 to 12 months, sometimes longer for platforms with regulatory review built in.

If a quote for something that sounds like tier two comes in at tier one pricing, that gap is the first thing to interrogate, not celebrate.

What actually moves the number within a tier

Two projects that sound similar in a sales call can land $40,000 apart once scoped properly. Six factors explain almost all of that variance.

1. Number of user roles. Every distinct role (admin, manager, field staff, customer, external partner) means separate permission logic, separate UI states, and separate testing paths. Going from two roles to five roughly doubles the permissioning and QA work, even if the core features stay the same.
2. Integrations. Each integration is its own mini-project: authentication, data mapping, error handling for when the other system is down, and ongoing maintenance when that system changes its API. Budget $3,000 to $15,000 per integration depending on how well documented the target API is.
3. Data migration. Moving existing records out of spreadsheets or a legacy system sounds simple until you find the duplicate customer records, the inconsistent date formats, and the fields nobody has used correctly in three years. Migrations routinely add 10 to 20 percent to a project's cost.
4. Compliance requirements. HIPAA, SOC 2, PCI DSS, or industry-specific regulation adds audit logging, encryption standards, access controls, and documentation that has no equivalent in a non-regulated build. This can add 20 to 40 percent to a tier two or tier three project.
5. Offline or mobile needs. A responsive web app is the baseline. A true offline-capable mobile app with local data sync adds meaningful engineering time, often 30 to 50 percent more than a comparable web-only scope.
6. Expected concurrency. A tool 12 people use during business hours is architecturally simple. A platform serving 5,000 concurrent users needs load testing, caching strategy, and infrastructure planning that a small internal tool never touches.

None of these factors are exotic. They are the honest reasons two quotes for "a customer portal" can differ by a factor of three, which is exactly the scenario covered further down.

Pricing models, and who carries the risk

How you pay changes who absorbs the cost when a project runs into the inevitable surprises.

Fixed price. You agree on a scope and a number up front. The agency carries the risk of underestimating; you carry the risk of change requests costing extra once the scope is locked. Fixed price works well for tier one projects with a clear, stable scope, and poorly for anything where requirements are likely to shift once you see the first working version.

Time and materials. You pay for actual hours worked, at an agreed rate, with no cap. You carry the risk entirely; if scope grows or the team underestimates a feature, the bill grows with it. This model suits projects where the requirements are genuinely uncertain at the start, such as an MVP where the first month of building is also the first month of learning what the product needs to be.

Capped time and materials. A hybrid: you pay hourly, but the agency commits to a ceiling they will not exceed without a formal change order. Risk is split. This is the model we default to for departmental and business-critical projects, because it keeps the incentive to work efficiently (unlike pure fixed price, which can incentivize corner-cutting once a team is behind) while giving you budget certainty.

There is no universally correct choice among the three. The right one depends on how well-defined your requirements already are, which is a separate question worth its own document (see our companion guide on writing a requirements document developers can actually use, linked from the custom software development service page).

The ongoing cost nobody puts on the first invoice

Budget 15 to 25 percent of the original build cost, every year, for maintenance, hosting, security patches, and small enhancements. On a $100,000 build, that is $15,000 to $25,000 annually, indefinitely, for as long as the system stays in use.

This is not a markup, it is reality. Frameworks release security patches. Third-party APIs change their contracts without much warning. Hosting needs scale as usage grows. A system that receives zero maintenance investment degrades within 18 to 24 months, first in small ways (a broken integration nobody notices for a week) and eventually in ways that force an expensive emergency rebuild. Any agency that does not mention this number during the sales process is not being straight with you about total cost of ownership.

Comparing quotes that differ by three times

This happens constantly, and it does not automatically mean one agency is dishonest. Before assuming the cheap bid is a scam or the expensive bid is a ripoff, check whether they are actually quoting the same project.

• Read the assumptions section, not just the total. A low bid frequently excludes data migration, assumes a single user role when you described three, or scopes "basic" reporting when you asked for exportable, filterable dashboards.
• Ask what happens after launch. A bid with no mention of post-launch support is a bid for a system that will be unmaintained the day it ships.
• Compare team composition. A quote staffed by one generalist developer and a quote staffed by a developer, a QA engineer, and a project manager will differ by a wide margin for legitimate reasons.
• Check the hourly rate implied by the total. Divide the quote by a reasonable estimate of hours for that scope. Rates under $25 an hour for a US-facing project usually indicate an offshore team with limited English-language client communication, high turnover risk, or both, none of which shows up in the initial quote.

Once you normalize for scope, team, and post-launch support, most of the apparent three-times gap usually shrinks to something explainable, and the remaining gap tells you something real about the two agencies.

Red flags in a suspiciously cheap quote

A few patterns are worth walking away from outright, regardless of how attractive the number looks.

• No discovery or scoping call before the number is given. A real quote requires understanding your process first.
• A single lump sum with no breakdown by feature, role, or phase.
• No mention of testing, QA, or a staging environment before launch.
• Payment structured entirely upfront, with no milestone tied to working software.
• A portfolio that shows screenshots but no live, working examples you can click through. Ours is public at our portfolio and our detailed case studies for exactly this reason.

Any one of these alone is not disqualifying. Two or more together usually means the low price reflects corners that will get cut later, often in testing, documentation, or the maintenance period you will need most.

FAQ

Do you charge for the initial quote or discovery call

No. A free 1-hour strategy call is how we scope the project honestly before any number gets attached to it, and it is also how we tell you if off-the-shelf makes more sense than a build at all.

Can a project move between tiers once it starts

Yes, in both directions. Scope sometimes grows once stakeholders see a working prototype, and sometimes shrinks once a team realizes a feature they assumed was necessary is not. This is exactly why capped time and materials pricing exists.

Is a departmental system with CRM or ERP integration priced differently than a standalone tool

Integration-heavy systems, particularly those syncing with CRM or ERP platforms, usually land at the higher end of their tier because of the mapping and error-handling work involved. If that is your primary need, our CRM and ERP development page has more specifics on typical scope.

What is the fastest way to get an accurate number instead of a range

Bring a written requirements document, even a rough one, to the first call. Specificity in, specificity out; vague requirements are the single biggest reason quotes come back as wide ranges instead of firm numbers.

The only way to know which tier and which pricing model actually fits your project is to talk through the specifics. Book a free 1-hour strategy call through the contact page and we will give you a real number, not a range.