Custom Software Development Costs: Budgets, Timelines, and Contract Models

Beyond Hourly Rates

Our guide on MVP development already covers the basic cost tiers for a first build, and our guide on building without a technical co-founder breaks down hourly rate ranges across freelancers, agencies, and fractional CTOs. Both are the right starting point if you haven't seen them, and this guide deliberately doesn't repeat either.

What neither of those guides covers is the layer most founders actually get wrong: an hourly rate, on its own, tells you almost nothing about what a project will actually cost, because it says nothing about how many hours the project will really take, how likely the timeline is to slip, or who bears the financial risk when it does. A $60/hour developer on a project that runs 40% over its estimated hours costs you more than a $90/hour developer who delivers on time. The contract model you sign determines who eats that overrun — you or your vendor — and most founders never examine that question until they're already living with the answer.

This guide covers what those two earlier posts leave out: full project budgets by scale rather than just hourly bands, the actual research behind why software timelines run over, the specific mechanical and risk-allocation differences between the four common contract models, how scope creep really inflates cost on a fixed-price engagement, and how a payment milestone schedule should be structured to protect both sides rather than just the vendor.

Real Project Budgets by Scale

These figures come from GoodFirms' own 2026 Custom Software Development Cost Survey, which breaks project scale into four tiers by both cost and typical timeline: small/MVP projects under $30,000, completed in one to three months, accounted for 14.1% of surveyed companies' typical projects; medium projects at $30,000–$100,000 over three to six months made up the largest share at 65.7%; large-scale projects at $100,000–$200,000 over six to twelve months accounted for another 14.1%; and enterprise projects at $200,000 or more, spanning twelve to twenty-four months, made up the remaining 6.3% (GoodFirms, “Custom Software Development Cost Survey,” 2026). The same survey found that most surveyed development companies use more than one pricing model in practice — 81.3% reported using time-and-materials at least some of the time, 65.6% reported using fixed-price, 59.4% reported using a dedicated-team or retainer arrangement, and 46.9% reported using milestone-based billing specifically, meaning these categories overlap rather than being mutually exclusive choices a company makes once and never revisits.

The reason a scale-based budget framing matters more than a rate-based one is straightforward: two projects at the identical hourly rate can land in completely different budget tiers depending on scope, integration complexity, and how many rounds of revision the requirements go through — and a founder planning runway needs the total number, not the per-hour number, to make a real financing decision. If you're budgeting for a fundraise or a runway plan, treat the figures above as the starting range for your project's tier, then add contingency on top — a topic the next section covers with real research on exactly how much contingency is typically warranted.

Within any one of these four tiers, the specific factors that push a project toward the top or bottom of its range are fairly consistent across projects, and worth naming explicitly since they're the levers you actually control when scoping. Third-party integrations are the single biggest cost driver most founders underestimate — a payment processor integration, a mapping API, or a sync with an existing CRM each individually looks simple, but each one adds its own authentication flow, its own error handling for when the third-party service is unavailable, and its own testing surface, and these costs compound rather than add linearly as the number of integrations grows. Custom design work, as opposed to using an existing component library or design system, is a second major driver — a fully custom visual design system typically adds real cost and time relative to building on top of an established one, precisely because every screen requires original design work rather than assembly from pre-built, pre-tested pieces. Regulatory or compliance requirements — healthcare data handling under HIPAA, payment data under PCI-DSS, or financial data under SOC 2 — add cost not just through the engineering work itself but through the additional testing, documentation, and often third-party audit work those standards require. And data migration from an existing system, when a project involves replacing something already in use rather than building on a blank slate, is routinely underestimated because the existing data is rarely as clean or as well-structured as anyone assumes until someone actually looks closely at it.

It's worth being explicit about a related, narrower data point that circulates widely in marketing content but that this guide could not independently verify to the standard it holds itself to: a frequently cited “average mobile app costs $132,480 and takes 13 months” figure, often attributed loosely to Clutch, could not be traced back to a specific, dated Clutch.co primary publication during this guide's research. What Clutch's own verifiable, sourced survey of 158 small-business owners who had built an app does show is a wide range — from under $10,000 to over $100,000 — with a real regional split: 46% of Northeast U.S. businesses surveyed spent over $50,000 on their app, compared to 25% in the South (Clutch, “App Development Cost Breakdown for Small Businesses”). The range, not a single average figure, is the more defensible number to plan around, and it's worth being skeptical of any single average-cost statistic you see cited without a clear, dated, primary source behind it — a pattern common enough in this specific corner of the industry that it's worth checking before you anchor a budget decision on it.

Why Software Timelines Slip

The most rigorously sourced research on this question comes from a 2012 McKinsey publication, “Delivering large-scale IT projects on time, on budget, and on value,” authored by Michael Bloch, Sven Blumberg, and Jürgen Laartz, based on a joint analysis by McKinsey and the University of Oxford's BT Centre for Major Programme Management (McKinsey & Company, October 2012). The study analyzed more than 5,400 IT projects, defining a “large” project as one with an initial budget greater than $15 million. Its headline finding: these large IT projects ran, on average, 45% over budget and 7% over schedule, while delivering 56% less value than predicted at the outset. A separate, particularly sobering finding from the same analysis: roughly 17% of large IT projects went so poorly they threatened the very existence of the company running them — described in the report as “black swan” outcomes. The study also found that every additional year a project runs adds roughly 15% to its cost overrun, which is a direct, quantified argument for keeping project durations as short as realistically possible rather than committing to multi-year builds upfront.

A more specific claim — that software projects specifically, within that same dataset, averaged 66% over budget and 33% over schedule — appears repeated across several independent secondary sources discussing the McKinsey/Oxford research, but this guide's research could not independently confirm that exact software-specific breakout directly against McKinsey's own primary text. It's included here only with that explicit caveat: treat the overall 45%/7%/56% figures as the well-corroborated headline finding, and treat any more specific “software projects run X% over” figure you see elsewhere with appropriate skepticism unless you can trace it to McKinsey's own report directly.

A second, long-running, independently useful data point comes from The Standish Group's CHAOS Report, a named, long-running research series tracking software project success and failure rates. Its 2020 edition, “Beyond Infinity,” drawing on a database of more than 50,000 project profiles from the preceding five years, found that 31% of software projects were fully successful (delivered on time, on budget, with the full agreed feature set), 50% were “challenged” (completed, but over budget, over time, or missing agreed features), and 19% failed outright or were canceled before completion. One additional, sharply practical finding from the same report: project size is one of the strongest predictors of success — small projects succeed at roughly 90%, while large projects succeed at under 10%. That single data point is a real, quantified argument for the broader industry preference toward breaking large builds into smaller, independently shippable phases, rather than a single monolithic project plan.

It's worth being precise about the limits of what this guide could verify on CHAOS Report specifics: later editions circulate in secondary literature with somewhat different figures (some citing success rates closer to 35% in more recent cycles), but this guide's research could not confirm those more recent figures against a readable primary text, so the 2020 “Beyond Infinity” figures above are the ones cited with confidence here. The exact numbers matter less than the consistent pattern across both the McKinsey/Oxford and Standish Group research: overruns on software projects are common, not rare, and the size and complexity of a project is one of the single best predictors of how likely it is to land close to its original estimate.

The practical implication for a founder budgeting a build: treat your development team's initial estimate as the floor of a realistic range, not the number to plan your runway around. Building in contingency — commonly in the range of 15–30% above the initial estimate, scaled up for larger or more novel projects, and scaled down for smaller, well-understood ones — is a more defensible planning approach than assuming the first number you're quoted is the number you'll actually pay. This is precisely the risk the next section's contract models are designed to allocate differently, which is exactly why the contract model you choose matters as much as the rate or the estimate itself.

Why estimates are wrong even when nobody made a mistake

It's worth being precise about a distinction that often gets lost in frustration when a project runs over: an inaccurate estimate is not automatically evidence of incompetence or bad faith. Software estimation is genuinely, structurally difficult in a way that estimating more physical, repeatable work usually isn't, because a meaningful share of any non-trivial project consists of work whose actual shape only becomes clear once the team is already inside it — an integration that behaves differently than its documentation suggested, an edge case in existing data that nobody could have discovered without looking at the real data itself, a requirement that seemed simple in a planning conversation but turns out to have several unstated variations once real users start describing what they actually need. This is precisely why widely used estimation techniques in software and project management — three-point (PERT) estimation, which combines an optimistic, a most-likely, and a pessimistic estimate into a single weighted figure, is the most common formalized version — exist at all: they're a structured acknowledgment that a single-point estimate is close to certain to be wrong, and that building a distribution of plausible outcomes into the planning process from the start is more honest than presenting one number as if it carries no uncertainty.

The practical consequence for a founder is to treat an estimate's precision as inversely related to how far into the future it's predicting and how novel the work is. A one-week estimate for a task the team has done many times before is reasonably reliable. A six-month estimate for a system with several integrations nobody on the team has built before carries real, structural uncertainty that no amount of upfront planning fully eliminates — which is exactly the dynamic the McKinsey/Oxford finding above about cost overruns compounding by roughly 15% for every additional year of project duration is measuring. The honest response to this uncertainty isn't to demand a more precise estimate from your development team; it's to build a contingency buffer that reflects the real, structural uncertainty in longer or more novel work, and to prefer shorter project phases with their own checkpoints over a single long estimate covering the entire build.

Contract Models Compared

Fixed-price contracts work by defining a scope of work upfront, then quoting a single total price to deliver that exact scope. Per Icertis's own published explainer on fixed-price contracting, in this model “if unforeseen complications arise or the project takes longer than expected, the service provider is responsible for covering any additional costs” — meaning the vendor, not the client, absorbs the financial risk of an inaccurate estimate, provided the original scope hasn't changed (Icertis, “What is a Fixed-Price Contract?” April 2025). Because vendors know they're accepting this risk, they typically build a contingency buffer into the quoted price — which is exactly why a fixed-price bid for the same defined scope often comes in higher than a time-and-materials estimate for identical work. The client's residual risk in this model isn't cost overrun; it's scope definition. If the original scope was written loosely or incompletely, every gap becomes a change-order negotiation rather than something the fixed price already covers — a dynamic the scope-creep section below covers directly.

Time-and-materials (T&M) inverts that risk allocation. Upwork's own platform documentation describes the mechanics precisely: on an hourly contract, the freelancer logs hours through a work diary, billing runs on a weekly cycle (Monday through Sunday UTC), the client has until the following Friday to dispute any logged time, and funds release the following Wednesday if undisputed (Upwork Help Center, “How hourly and fixed-price contracts are different on Upwork”). The client pays for actual time worked, whatever that ends up being — which means if the estimate was wrong, or the scope grows, the client bears that cost directly, rather than a vendor having silently priced the risk into a fixed number upfront. The advantage this buys the client is flexibility: requirements can change mid-project without triggering a formal change-order negotiation, since the contract was never based on a single locked scope in the first place. The trade-off is that the client carries the budget uncertainty a fixed-price contract would have transferred to the vendor.

Dedicated-team engagements work differently from both of the above: rather than pricing a specific scope or billing specific hours, the vendor recruits, employs, and administers (payroll, benefits, equipment) a team that works full-time and exclusively on the client's product, under the client's own day-to-day direction and prioritization. This description is consistent across multiple software-agency industry sources, though it's worth noting explicitly that no single named legal or academic authority defines the dedicated-team model with the same precision as Upwork documents its own hourly and fixed-price mechanics — it's an industry-standard arrangement more than a formally codified one. In practice, the client controls scope and priorities much like an in-house team, and bears the risk of misallocated management time — a dedicated team is only as effective as the client's own ability to direct it well, since the vendor's role shifts from owning outcomes (as in fixed-price) to supplying committed capacity. Billing is typically structured per engineer, per month, on an ongoing basis rather than tied to specific deliverables.

Retainer arrangements are the loosest of the four: rather than scoping a specific project, a client pays a recurring fee for guaranteed access to a set amount of the vendor's capacity — commonly used for ongoing maintenance, incremental feature work, or advisory relationships that don't map cleanly to a single defined deliverable. Per the GoodFirms 2026 survey cited above, roughly 59.4% of surveyed development companies reported using a dedicated-team or retainer arrangement at least some of the time, reflecting how common this model has become for ongoing, rather than one-off, engagements.

A hybrid structure, worth naming explicitly since it doesn't fit neatly into any of the four categories above, is increasingly common in practice: fixing the price for the parts of a project that are genuinely well-understood (a defined set of core features, an established integration pattern), while running the less-certain parts of the same engagement — a novel integration, a feature the team hasn't built the equivalent of before — on time-and-materials. This isn't a fifth formal model so much as a deliberate application of the same underlying logic covered above at the level of individual project components rather than the whole engagement: put fixed-price risk where the scope genuinely supports it, and leave time-and-materials flexibility where it doesn't, rather than forcing an entire multi-part project into a single pricing model that fits some of its parts better than others.

Scope Creep and Change Orders

Scope creep is not a fringe risk — it's the norm, and the research on its prevalence is specific and well documented. PMI's own PM Network publication, in a July 2018 article by journalist Catherine Elton titled “Scope Patrol,” reports directly from PMI's 2018 Pulse of the Profession research: “PMI's 2018 Pulse of the Profession found that 52 percent of projects completed in the last 12 months experienced scope creep or uncontrolled changes to the project's scope — up from 43 percent five years ago” (Catherine Elton, “Scope Patrol,” PM Network, PMI, July 2018). That article quotes several named practitioners directly on the underlying dynamics: Harris Apostolopoulos, director of the transformation PMO at Saudia Cargo in Jiddah; Athanasios Arkoudopoulos, a cybersecurity portfolio and program manager at NXP Semiconductors in Eindhoven; Monica Sacco, worldwide project management profession leader at IBM; and Claudia Farias, director of program management at Future Digital Bank, Citibanamex — a genuinely global, cross-industry set of practitioners independently describing the same pattern: scope creep is rising, not falling, as stakeholder expectations increase.

“PMI's 2018 Pulse of the Profession found that 52 percent of projects completed in the last 12 months experienced scope creep or uncontrolled changes to the project's scope—up from 43 percent five years ago.”

— Catherine Elton, “Scope Patrol,” PM Network, PMI, July 2018

The GoodFirms 2026 survey adds a directly cost-relevant figure on top of that prevalence data: 65.6% of surveyed development companies reported that scope creep typically inflated project cost by 10–25%, and separately, 86% cited changing client needs as a recurring issue even on projects that began with clearly defined goals. Read together, the pattern is consistent and important: even a well-scoped project, run by a competent team, faces a real, quantified, majority-likelihood chance of scope changing mid-flight — and on a fixed-price contract specifically, every one of those changes is a moment where the original price no longer covers the actual work being requested.

This is exactly why a formal change-order process matters as a contractual mechanism, not just a courtesy. A well-drafted fixed-price contract should specify, in writing, before work begins: how a scope change gets proposed and documented, who has authority to approve added cost or timeline on either side, and how the resulting price and schedule adjustment gets calculated and agreed before the additional work starts — not after it's already been done. Without this mechanism written into the contract upfront, scope creep on a fixed-price engagement tends to resolve informally and asymmetrically: either the vendor absorbs unpaid extra work to preserve the relationship (building resentment and cutting corners elsewhere to compensate), or the client ends up paying disputed “out of scope” charges they never explicitly agreed to in advance. A defined change-order process, agreed before anyone needs it, converts an emotionally fraught negotiation into a straightforward, pre-agreed procedural step.

There's a useful distinction worth drawing between scope creep that originates with the client and scope creep that originates with the development team, since the two call for different responses. Client-originated scope creep — a new feature request, a changed requirement discovered mid-project — is the more common pattern the PMI research above documents, and the right response is the formal change-order process: document the new request, price it explicitly, and get it approved before building it, rather than absorbing it silently into the existing scope. Team-originated scope creep is a subtler and less discussed pattern: a developer noticing a “better” way to build something and quietly expanding the work beyond what was actually requested, out of genuine craftsmanship rather than any bad intent. Both inflate cost and timeline in the same way, but only the first one shows up naturally in a client-facing change-order conversation — which is why a periodic, structured check-in against the original scope (not just a request-driven one) is worth building into a project's cadence regardless of which contract model governs it.

Structuring Payment Milestones

On fixed-price contracts specifically, Upwork's own platform mechanics illustrate one concrete, real-world implementation of milestone-based payment: the total project fee is split into individual milestones, each of which the client funds into escrow before the corresponding work begins, and the client then has a defined 14-day window to review and approve the delivered work — with funds automatically releasing to the freelancer if that window passes without a dispute (Upwork Help Center). This structure — pre-funded escrow, a bounded review window, and an automatic default toward release rather than indefinite withholding — is a genuinely well-designed template even outside Upwork's specific platform, because it protects both sides: the vendor isn't working indefinitely on trust that payment will eventually arrive, and the client isn't paying for undelivered or unreviewed work.

On the specific question of how to size each milestone, legal-content publisher LegalClarity's guidance is a useful, precise framework even though it isn't attributed to an individually named attorney: milestone payment percentages should track the actual work effort or cost incurred at each phase, rather than following a round, arbitrary split — “if foundation work represents ~20% of total project cost, the foundation milestone should be close to 20% of contract price” ( LegalClarity, “What Is a Milestone Payment in a Contract?” 2026). The same source describes a common retention (or holdback) practice of withholding 5–10% of each milestone's payment until the entire project is complete and any defects are corrected — a practice with a direct analog in construction-industry retainage, where federal contracts commonly cap retainage at 10%. The underlying logic is symmetric protection: retention gives the client leverage to ensure final defect correction actually happens, while capping it at a modest percentage (rather than withholding a much larger share) keeps the vendor adequately funded to keep working through the project's later, often more labor-intensive phases.

It's worth being direct about a common milestone-structuring mistake in both directions. Front-loading payment — a large percentage due at signing, before meaningful work is delivered — creates real risk that a vendor could walk away after collecting the early payment with little delivered in return. Back-loading payment too heavily — withholding the bulk of payment until final delivery — creates the opposite risk: a vendor with insufficient cash flow to properly staff the project's later, often hardest phases, which can produce exactly the corner-cutting and quality problems a client was trying to protect against by withholding payment in the first place. The specific percentage splits that circulate widely in agency marketing content (such as “20% upfront, 30% at midpoint, 50% on completion”) are common informal industry conventions rather than a rule from any single authoritative source, and are worth treating as a reasonable starting template to adapt to your specific project's actual effort distribution, per LegalClarity's effort-based framework above, rather than as a fixed formula to apply uncritically.

Choosing the Right Model for Your Project

One factor worth weighing alongside all four of the questions below, rather than as a separate fifth consideration, is where your vendor is actually located, since geography interacts with every one of them. A team in a significantly different time zone changes how a change-order conversation actually plays out in practice — a same-day clarifying question can turn into a next-day answer purely from the clock, which compounds over a project's life into real schedule drag even when nobody involved is doing anything wrong. It also changes how much of the estimation uncertainty covered above you can resolve through quick, informal conversation versus through more formal, written specification, since a team you can talk to in real time can clarify an ambiguous requirement in minutes, while a team twelve hours offset may only get that clarification the next working day. None of this makes a distributed or offshore arrangement the wrong choice — cost and access to specialized skill are real, legitimate reasons to work across time zones — but it's a genuine factor in how much scope-definition rigor and written change-order discipline a contract needs, not an incidental detail.

Bringing the research above together into an actual decision process:

1. 1

   Budget by project tier, then add contingency

   Use the scale-based ranges above as your floor, then add 15–30% contingency scaled to your project's size and how novel the work is — not the vendor's initial quote alone.

2. 2

   Match the contract model to how stable your scope actually is

   Fixed-price for a genuinely locked scope; time-and-materials or a dedicated team when requirements are still evolving — choosing the wrong model doesn't eliminate risk, it just hides who's holding it.

3. 3

   Write the change-order process into the contract before you need it

   Given how common scope creep is across the research above, a defined process for proposing, approving, and pricing scope changes should exist before signing — not be improvised mid-project.

4. 4

   Size milestones to actual effort, with a modest retention

   Match each milestone's payment to the real work effort of that phase, and consider a 5–10% retention held until final delivery and defect correction — enough to protect you, not so much it starves the vendor.

Frequently Asked Questions

None of the four contract models covered here is inherently better than the others — each allocates risk differently, and the right choice depends on how well-defined your scope actually is, how much flexibility you need, and how much cost certainty matters at your specific stage. What the research above should change is how you plan around whichever model you choose: budget from the real, scale-based ranges rather than a single average figure, add contingency informed by how often large IT projects actually run over, and write the change-order and milestone mechanics into the contract itself — rather than discovering, mid-project, that the price you agreed to and the scope you actually need were never quite the same thing.