Custom software pricing models explained
Software development pricing models compared: fixed price, time and materials, dedicated teams, and hybrids, plus who carries the risk when scope changes.
The way a firm charges you shapes how the project behaves. Pricing is not just a number at the bottom of a proposal, it decides who carries the risk when things change, how flexible the scope can be, and whether the incentives line up with your goals. It also sits on top of a real labor market. US software developers earned a median wage of $133,080 in May 2024 with a mean hourly wage of $69.50 according to the Bureau of Labor Statistics, and US custom development shops typically bill in the $75 to $250 per hour range once overhead, benefits, and margin are added. Whatever model you pick sits on those numbers. This guide walks through the main software development pricing models, what each one hides, and how to match a model to the kind of project you actually have.
Fixed price: when it fits
In a fixed-price engagement you agree on a defined scope and a total number up front. The firm takes the risk that the work runs long. That sounds appealing, and for the right project it is.
Fixed price works when the requirements are genuinely stable and well understood: a clear integration, a well-specified module, a rebuild of something that already exists. The catch is that firms are not charity. To absorb the risk of overrun, they add padding to the estimate, so you often pay a premium for the certainty. That premium is not paranoia. The historical Standish CHAOS data put the average cost overrun on challenged projects at 189 percent of the original estimate, and any firm quoting a fixed number is pricing against that possibility. Because every change touches the agreed scope, fixed price also tends to breed change orders and friction the moment reality diverges from the spec. If your requirements will discover themselves as users engage, fixed price fights you the whole way. Our deeper comparison of fixed price vs time and materials covers where that risk premium hides.
Time and materials: pros and pitfalls
Time and materials (T&M) bills for the hours actually worked at agreed rates. You carry the scope risk, but you also get flexibility: you can reprioritize every sprint, kill features that turn out weak, and add ones you did not foresee.
The strength of T&M is honesty about how software really gets built, which is iteratively. It also matches how scope actually behaves in practice. PMI's 2018 Pulse of the Profession found 52 percent of projects experience scope creep, up from 43 percent five years earlier, so a model that expects change beats one that fines you for it. The pitfall is that T&M demands trust and visibility. Without regular demos and transparent reporting, it can drift, and you have no fixed ceiling to point at. The fix is not to avoid the model, it is to insist on a working demo each sprint and clear tracking of where hours go. When you can see the software improving every two weeks, T&M is the most efficient way to build something whose shape is still forming.
Dedicated team / retainer model
A dedicated team model is T&M with commitment. You pay for a defined team, usually monthly, and that team works only on your roadmap. It is the model that most resembles having your own engineering group without the hiring, benefits, and management overhead.
This fits companies with an ongoing product, not a single deliverable. It also sidesteps a tight hiring market: the BLS projects software developer employment growing 15 percent from 2024 to 2034, much faster than the average occupation, which keeps senior talent expensive and slow to recruit directly. Renting a standing team converts that hiring problem into a monthly line item. Because the team stays with you, knowledge compounds instead of resetting with each new statement of work. Velocity tends to climb over time as the team learns your domain and codebase. The trade-off is that you need enough sustained work to keep a team busy, and you take on the responsibility of feeding it a clear backlog. For a longer horizon, our piece on dedicated team vs fixed project cost compares the total spend across a multi-phase roadmap.
Milestone-based and capped models
Between the extremes sit hybrids. Milestone-based pricing ties payment to delivered, accepted chunks of work, so you pay as value lands rather than up front. Each milestone has measurable acceptance criteria, which turns "is it done" from an argument into a test.
A capped T&M model gives you the flexibility of hourly billing with a not-to-exceed ceiling, splitting the risk between both sides. Another common hybrid fixes the price of a discovery phase, then moves to T&M for the build once the unknowns are smaller. These structures exist because pure fixed and pure T&M each fail at the edges, and a well-chosen hybrid can give you predictability where you need it and flexibility where you do not.
Risk allocation across each model
Every pricing model is really a decision about who owns the risk of the unknown. Here is the short version:
| Model | Who carries scope risk | Best when |
|---|---|---|
| Fixed price | The firm (priced in) | Scope is stable and well defined |
| Time and materials | You | Requirements will evolve |
| Dedicated team | You | Ongoing product with steady work |
| Milestone / capped | Shared | You want structure plus flexibility |
The mistake buyers make is chasing the model that appears cheapest or safest on paper, without asking what happens when the project changes. The risk is not hypothetical. McKinsey and Oxford, studying more than 5,400 large IT projects, found they run 45 percent over budget on average and deliver 56 percent less value than predicted. Fixed price looks safe until you need a change and discover every change is a negotiation. T&M looks risky until you realize the alternative was paying a premium for false certainty.
What the numbers look like in practice
Rate structure only tells you the price per hour. The total depends on scope. Published US ranges for custom builds cluster like this:
| Project size | Typical range | Notes |
|---|---|---|
| Small app / single workflow | $100,000 to $200,000 | narrow scope, few integrations |
| Mid-sized business system | $200,000 to $400,000 | multiple modules, real integrations |
| Enterprise-grade platform | $400,000 and up | heavy compliance, scale, custom logic |
Those bands come from 2024 custom software cost surveys and match what senior US teams charge at the rates above. They are planning numbers, not quotes: two projects with the same feature list can differ by a factor of two depending on non-functional requirements, data volume, and how much integration work hides behind each screen. For a fuller breakdown, our guide on how much custom software costs sets realistic ranges by project type.
Choosing a model for your project type
Start with one question: how well do you actually understand what you are building. If the answer is "completely, down to the field level," fixed price or milestones can work and give you clean predictability. If the honest answer is "we will learn a lot once real users touch it," T&M or a dedicated team will serve you far better, because they let the product change without punishing you for it.
Also weigh the horizon. A single, bounded deliverable suits fixed or milestone pricing. An evolving platform you plan to grow for years suits a dedicated team. The reason the horizon matters is compounding: with US developer time running at a mean of roughly $69.50 an hour before margin, a team that gets faster as it learns your domain returns more per dollar over a multi-year build than one that resets its context with every new statement of work. Whatever you pick, tie payment to accepted work with clear criteria, keep a demo cadence so you can see progress, and make sure you own the source code and infrastructure regardless of billing model. When you are ready to price your specific project, get a technical proposal and we will recommend a model that fits the work rather than the sales pitch.