A founder called us last spring with a spreadsheet and a knot in her stomach. She'd collected four bids for the same custom software development project — an operations tool to replace a tangle of spreadsheets — and they ranged from $38,000 to $310,000. Same brief. Same feature list. An eight-fold spread. Her question wasn't really "which bid is right." It was the one every buyer eventually asks out loud: how much does custom software cost, really?
Here's the direct answer. Custom software typically costs $40,000 to $150,000 for a small, focused build, $150,000 to $400,000 for a mid-size application, and $400,000 to $1.5 million or more for a large, enterprise-grade system — driven mostly by scope, integration count, and who's writing the code and where. Those are ballparks, not quotes. The rest of this post explains what moves you inside each band, so you can read a proposal instead of just flinching at the number at the bottom.
Because "custom software" isn't one thing. A quote is really an estimate of hours × rate × risk, and every one of those three variables swings hard.
Scope is the obvious lever. A tool with 8 screens and one integration is a different animal from a platform with 40 screens, role-based permissions, a mobile app, and six external systems it has to stay in sync with. But the two hidden levers cause more sticker shock than scope does:
Who's building it, and where they sit. A senior US onshore team and an offshore team can quote the same project at rates that differ by 5x. More on that below.
How much uncertainty is baked in. Vague requirements, an unproven integration, or a "we'll figure out the data model later" plan all get priced as risk — either as padding or, worse, as a low bid that balloons mid-build.
At CodeStringers, we've learned to read the spread the founder saw as a signal, not noise. When bids vary 8x, it usually means the vendors are quoting four different projects because the brief left too much open. Tightening the scope compresses the range fast.
The cleanest way to anchor a budget is by project size and complexity. Here's where 2026 market rates land, synthesized from published development-firm pricing benchmarks.
Project size | Typical cost | What it looks like | Rough timeline |
Small / MVP | $40,000 – $150,000 | One core workflow, a handful of screens, 1–2 integrations | 2 – 4 months |
Mid-size | $150,000 – $400,000 | Multiple user roles, several integrations, reporting, some automation | 4 – 9 months |
Large / enterprise | $400,000 – $1.5M+ | Many modules, heavy integrations, compliance, scale requirements | 9 – 18+ months |
AI-native product | $1M – $2M+ | Custom model work, data pipelines, LLM orchestration on top of the above | 12 – 24+ months |
Industry cost guides put small apps in the $30,000–$150,000 range and mid-complexity applications between roughly $150,000 and $300,000, with enterprise builds running from $250,000 to $5 million and beyond depending on the domain (SolTech, Keyhole Software). The bands above blend those, then widen the top end to reflect what AI features and deep compliance now add.
One caveat we tell every client: the size label is downstream of the requirements, not the other way around. Teams routinely walk in describing a "small" tool that, once the workflows are mapped, is squarely a mid-size build. That's not a bait-and-switch — it's what happens when a real business process meets an honest estimate.
Most custom software is still priced, underneath everything, in developer hours. So the single biggest driver of your total is the blended hourly rate — and that's mostly a function of geography and seniority.
Region / model | Typical hourly rate |
US onshore — small to mid-market firms | $90 – $250 |
US onshore — enterprise consultancies | $250 – $400+ |
Nearshore (Latin America) | $44 – $82 |
Eastern Europe | $25 – $99 |
Offshore (India, Vietnam, Philippines) | $27 – $55 |
FullStack's 2025 price guide puts US small-class firms at $90–$160/hour and mid-market at $120–$250, with enterprise-class firms charging $400+ and some as high as $900; it pegs Latin America (nearshore) at $44–$82 and Asia-based offshore work at $27–$55 (FullStack). Broader surveys land in the same neighborhood — roughly $25–$60/hour offshore versus $100–$300+ for premium onshore consultancies (ADEVS).
Rate is not the same as cost, though. A $40/hour team that needs three revisions, has an eight-hour communication lag, and ships a fragile data model can end up more expensive than a $150/hour team that gets it right the second time. We've been called in to rescue more than one "cheap" build where the total spend, once you counted the rework, quietly passed what a mid-market onshore quote would have been.
A common budgeting mistake is treating the price tag as "the code." Engineering is the biggest slice, but a healthy project spreads the money across several phases — and the non-code phases are where quality and cost-control live.
Discovery and requirements — mapping the real workflow, defining scope, de-risking the hard parts. Skimp here and you pay for it later in change orders.
UX and product design — wireframes, flows, and the interface. Design commonly runs 15–25% of a project (Saritasa).
Engineering — the build itself, typically the largest share at roughly 60–75% of total cost (Saritasa).
QA and testing — finding the defects before your users do.
Integrations and data migration — often underestimated; each external system you connect adds cost and risk.
Deployment and project management — getting it live, and the coordination overhead that keeps it on the rails.
The phases connect in sequence, and the early ones set the ceiling on how well the later ones can go. A rushed discovery doesn't save money; it defers the cost to engineering, where hours are more expensive to spend.
Timeline and budget are the same conversation from two angles — you're paying a team per unit of time, so months and dollars move together.
Even a lean project generally takes three to six months from planning to deployment (Saritasa). Mid-size applications commonly land in the four-to-nine-month range, and enterprise systems stretch past a year. Two forces pull timelines longer than buyers expect: integrations (every external system is a negotiation with someone else's software) and decision latency on the client side (approvals, access, and answers that don't come back fast enough).
A useful reframe we offer clients: you can often trade scope for speed but rarely trade money for speed past a point. Throwing more engineers at a late project tends to slow it down — the classic result that adding people to a delayed software project makes it later, because coordination cost grows faster than output. Phasing the build is almost always the better lever.
The cheapest custom software is the custom software you don't build. Before you price a project, it pays to ask whether an off-the-shelf product plus some configuration would do the job for a fraction of the cost.
Custom wins when your process is a genuine differentiator, when no product fits your workflow without contortions, or when you're stitching together systems that don't talk to each other. Buy wins when your need is common, a mature product exists, and "good enough and available Monday" beats "perfect in nine months." Many of the strongest builds we've delivered are actually hybrids — a packaged platform for the commodity parts, custom code and business systems integration for the parts that make you you.
We walk through this trade-off in detail in our guide on how to decide between building and buying software. Getting this decision right is often worth more than any negotiation on hourly rate.
Launch day is not the finish line — it's the start of the recurring bill most first-time buyers forget to budget for. Software needs bug fixes, security patches, dependency upgrades, and changes as your business shifts.
The widely cited industry benchmark is 15–20% of the initial build cost per year for ongoing maintenance and support (Savi), and other guides put the range at 15–25% (ADEVS). Highly regulated systems — fintech, healthcare, government — run higher, sometimes 40–60% of the build cost annually once you factor in compliance, audits, and security work (ADEVS).
So a $200,000 build should carry roughly $30,000–$50,000 a year in your budget from day one. Over a five-year life, maintenance can quietly equal or exceed the original build cost — which is exactly why total cost of ownership, not the build quote, is the number that should drive the decision.
Numbers are easier to trust when you can see the math. Here's a realistic mid-size build, priced end to end. State the assumptions, walk the arithmetic.
The project. An internal operations platform for a services company: customer records, a job-scheduling workflow, role-based access for three user types, a customer-facing status portal, reporting dashboards, and integrations with an existing accounting system and email. Call it a mid-size build.
Assumptions. A blended team (product designer, two to three engineers, part-time QA and project lead) at a blended $110/hour — a mid-market rate that mixes senior onshore leadership with nearshore engineering. Estimated effort: about 1,900 hours across all phases over roughly six months.
Phase | Share | Cost |
Discovery & requirements | 10% | $20,900 |
UX & product design | 18% | $37,620 |
Engineering | 50% | $104,500 |
QA & testing | 12% | $25,080 |
Integrations & deployment | 10% | $20,900 |
Total build | 100% | $209,000 |
Then the part the spreadsheet usually omits: at 18% annual maintenance, budget about $37,600 per year afterward. Over three years, that's roughly $322,000 all-in — a 54% jump over the build quote alone.
Change the rate to $45/hour offshore and the build drops toward $85,000; change it to a $300/hour enterprise consultancy and it climbs past $570,000 for the same feature list. Same project, three very different totals — which is why "how much does custom software cost" can only ever be answered with a range until the rate, scope, and risk are pinned down.
Cost overruns are the norm, not the exception. Across a 16,000-project database, 18% of IT projects that exceed budget by more than 50% overrun by an average of 447% (Bent Flyvbjerg, via BudgetOverrun.com), and the PMI Pulse of the Profession found 43% of projects exceed their budget (PMI, via BudgetOverrun.com). The failure modes are predictable, which means they're largely preventable.
Left the scope vague. Loose requirements are the number-one source of change orders. Invest in discovery instead.
Underpriced the integrations. Each external system is a source of cost and delay. Count them all up front.
Chased the lowest bid. A number too far below the others usually isn't efficiency — it's a scope that will grow after you sign.
Skipped the maintenance line. Then treated year-one support as a surprise instead of a plan.
The single most effective control is phasing — build the core, ship it, learn, then fund the next slice against real usage instead of a guess. It caps your downside and gives you an exit ramp at every stage. It's the same discipline we bring to helping teams move from an MVP to full-scale without over-committing the budget before the product has proven itself. For a deeper look at controlling spend on outsourced builds specifically, see our guide on managing product outsourcing costs.
Start with the range, not the quote. Use the size bands to sanity-check any proposal, use the rate table to understand why two bids differ, and always add the maintenance line before you compare options. A proposal you can read on those three axes — scope, rate, and total cost of ownership — is a proposal you can negotiate instead of just accept or reject.
If you want a straight, no-obligation read on where your specific project lands, book a free consultation. We'll pressure-test your scope, flag the cost drivers hiding in the requirements, and give you a range you can actually plan around — whether or not we're the ones who build it. You can also see how we structure engagements in how we engage.
By the CodeStringers Team — Zoho Experts & Custom Software. We're a custom software and systems-integration consultancy that helps small and mid-sized businesses scope, price, and build software that pays for itself — and we'd rather tell you the real number up front than surprise you with it later.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
A usable quote lists the phases separately: discovery, design, engineering, testing, integrations, data migration, deployment and project management, each with hours and rates or a fixed figure. It names the people or roles doing the work, states what is excluded, and says how changes are priced. It should also show the assumptions behind the estimate, such as the number of integrations and user roles. A single number with no breakdown cannot be compared with anything.
Hosting and infrastructure, third-party service fees such as email, maps or payment processing, software licences the system depends on, security patching, dependency upgrades, monitoring and backups, and the support time when users find problems. Add the cost of changes as the business learns what it actually needs. A budget that stops at launch typically covers the first year poorly; ask the vendor for an annual running-cost estimate alongside the build price.
Cut scope, not rigour. Ship the one workflow that matters first and defer the rest, reduce the number of integrations in the first release, reuse proven components and managed services instead of building from scratch, and spend properly on discovery so engineering hours are not wasted on rework. Avoid cutting testing, design or project management, since those are where cheap builds become expensive. A smaller, finished product costs less than a larger, unfinished one.
Yes, when the scope is well defined and stable, typically after a discovery phase has produced a specification both sides accept. Before that, a fixed price includes a risk premium for everything the vendor cannot see, and changes become formal change orders. A common pattern is a fixed price for discovery, then either a fixed price for a tightly scoped first release or time and materials with a cap for the rest.
Fixed-price projects are usually paid in instalments tied to milestones, with a deposit at signing and the balance spread across delivery and acceptance. Time and materials projects are invoiced on a regular cycle, often every two weeks or monthly, against submitted timesheets. Either way, tie payments to something you can verify, such as a demonstrated milestone or a timesheet, and agree what acceptance means before the first invoice arrives.
Usually, and in ways that are easy to miss. Beyond the engineering of the feature itself, there is data preparation, evaluation of the model's output, guardrails and human review for anything that acts on its own, and an ongoing usage cost for the model provider that scales with traffic. The post's cost bands put AI-native products above conventional enterprise builds for those reasons. A narrow, well-defined AI feature inside an ordinary application costs far less than an AI-native product.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
