Software Development Pricing Models: Who Carries the Estimate Risk
Every guide to this question lists the same three models and tells you each has trade-offs. None of them tells you the one thing that separates them, which is who pays when the estimate turns out to be wrong. This is that page, written by a studio that quotes fixed prices and will tell you when not to ask for one.
There are three pricing models in custom software development and they differ in exactly one variable: who pays when the estimate is wrong. Fixed price puts that on the vendor. Time and materials puts it on you. A dedicated team puts it on you and asks you to supply the management as well. Everything else written about these models is downstream of that one sentence. The useful variants are time and materials with a not-to-exceed cap, which splits the risk, and outcome-based pricing, which is rare because the measurement clause is harder to write than the software.
We sell one of these models, so read this knowing that. Kinetico quotes a fixed price per scoped version, published as three tiers inside $15,000–$50,000 over 6–12 weeks on the pricing page, and where that money goes inside a build is broken out line by line in the cost breakdown. What follows includes the section where that is the wrong thing for you to buy, because a guide that never says so is a sales page. The arithmetic below is arithmetic and you can redo it. The things attributed to other vendors are quoted from their own pages, which we read in full rather than skimmed.
Key Takeaways
- •The models differ in who absorbs an estimate error. Fixed price: the vendor. Time and materials: you. Dedicated team: you, plus the cost of managing it. Everything else follows from that.
- •A fixed quote and an hourly estimate are not the same kind of object and cannot be compared as numbers. The fixed price contains a risk premium; the estimate contains no obligation at all. The estimate is always lower on paper and not always lower at the end.
- •A rate tells you nothing without the hours. The same $30,000 buys 1,000 hours at $30 and 250 hours at $120. Ask for hours and the seniority mix, not the rate.
- •The change-order clause is the real price. Ask what happens in three separate cases: you swap something of the same size, you add scope, and the vendor finds work nobody scoped. Most of the difference between two similar quotes is in those three answers.
- •Milestones tied to calendar dates transfer no risk. A date arrives whether or not the software does. Tie payments to a deployed build you can open in a browser.
- •Ask a time-and-materials vendor to cap the number they just estimated. A refusal is not an outrage, it is information: they do not trust the estimate either.
The one variable that separates the models
Nobody can estimate software accurately. That is not a criticism of estimators, it is the nature of building something that has not been built before, and every model on this page is a different answer to the same question: given that the number will be wrong, who pays for the gap? Once you hold that question in mind the models stop being a menu of styles and become a single decision about risk.
| Model | What you buy | Who pays for a wrong estimate | What it makes the vendor optimise for | Honest when |
|---|---|---|---|---|
| Fixed price | One number for a written scope | The vendor | Pinning the scope down, then finishing | The thing has an edge, so it can be described, built and finished |
| Time and materials | Hours actually worked, at a rate | You | Transparency of reporting, because that is all you have | The work is open-ended and you can steer it week to week |
| T&M with a not-to-exceed cap | Hours worked, never above a ceiling | Yours below the cap, theirs above it | An estimate the vendor is willing to stand behind | Almost always. It is the compromise both sides can defend |
| Dedicated team | Capacity: people, per month | You, plus the management | Keeping seats filled | You have a long roadmap and someone in-house to run it |
| Outcome-based | A result, priced to its value | Nominally the vendor | Defining the outcome narrowly enough to be provable | Rarely. The measurement clause is harder to write than the software |
The fourth column is the one to sit with. A pricing model is an incentive structure, and it quietly decides what the people building your product are rewarded for noticing. Under a fixed price, an hour spent tightening the scope before work starts saves the vendor money, so the scoping is thorough and sometimes uncomfortably pedantic. Under time and materials that same hour is billable either way, so the pressure to pin things down early is not there. Neither of those is dishonesty. It is what the contract pays attention to.
Read the existing guides knowing who wrote them
Search this question. Every result on the first page comes from a company that sells software development. That is worth knowing before you weigh what they recommend, and it is not a conspiracy: nobody else has a reason to write two thousand words about billing models. But it does mean these guides are written from the seller's side of the table, and one of them says so outright.
Apropo subtitles its guide “a complete guide to software development pricing models for IT agencies” and opens by framing the choice in terms of the agency's own margin: the model you pick, it says, “decides whether estimation errors destroy margin or get absorbed without drama.” It is a good, honest piece of writing that happens to be addressed to the other party. Read as a buyer, its most useful line is the warning it gives agencies about themselves: without precise scope, documented assumptions and a real change-request mechanism, a fixed price is “a bet.” Check those three things before you accept one.
ScienceSoft publishes four models (time and materials, time and materials with a cap, fixed price, and monthly or per-ticket fees for support) and is unusual in running a table of pricing risks named from the vendor's side. Anyone considering an hourly engagement should read one passage of it: a vendor, it notes, “may price the fixed-scope task under T&M and then attempt to increase the budget by intentionally delaying the deliverables and claiming more billable hours.” That is a large development company writing down the incentive problem with hourly billing on its own website.
JayDevs covers fixed price, time and material, dedicated team and a mixed model, and adds pay-per-hire. Its navigation sells IT staff augmentation and per-role hiring, which is also the model its guide treats most warmly. Again: not dishonest, just gravity. Read any of these pages with the services menu open in another tab. Then notice which model the article finds fewest problems with.
What is inside a fixed price
A fixed price is not a discount and it is not a bulk rate. It is an estimate plus a risk premium, and the premium is the product you are buying. If a vendor believes the work is 400 hours, the fixed price covers the world in which it turns out to be 520, because that overrun is now theirs. A vendor who quotes a fixed price with no premium in it has either not read the scope or is planning to come back and renegotiate, and the second is more common than the first.
The other half of the number is where the work goes. These are the phase shares Kinetico publishes, and they are stable across builds because the ratio between designing a screen and building it does not move much:
| Phase | Share | What it buys |
|---|---|---|
| Scoping & product definition | 5 – 10% | One 30-minute call → written scope: modules, screens, states, integrations, weeks, one number |
| Product design | 20 – 25% | Flows, every screen and state, a coded design system in the repository |
| Engineering | 50 – 60% | TypeScript end to end: frontend, API, database, auth, roles, payments, integrations, admin |
| QA, launch, handover | 10 – 15% | Tests, production deploy in your accounts, monitoring, docs, repo and accounts transferred |
Run those shares over a Standard-tier build and the money lands like this. It is arithmetic on the row above, not a quote from a project:
| Line | Share | Amount |
|---|---|---|
| Scoping & product definition | 7% | $2,100 |
| Product design | 23% | $6,900 |
| Engineering | 57% | $17,100 |
| QA, launch, handover | 13% | $3,900 |
| Total (Standard tier, 8 weeks) | 100% | $30,000 |
Argue with a vendor about two lines in that table. The first is that QA, launch and handover is a real line with real money in it. When a quote comes in surprisingly low, this is usually the line that was removed, and you will not notice until the last fortnight. The second is that scoping is paid work. A vendor who scopes for free is either recovering the cost inside the build price or scoping thinly, and thin scoping is the condition under which Apropo says a fixed price becomes a bet.
A rate is not a price, and the arithmetic shows it
Hourly rates are the most quoted and least informative number in this market. A rate is one term in a multiplication and the other term is the one that decides what you get. Hold the budget still at $30,000 and vary only the rate:
| Rate | $30,000 buys | Roughly | How to read it |
|---|---|---|---|
| $30 / hour | 1,000 hours | Roughly 6 person-months | Either a very junior team or a rate that will not survive the project |
| $60 / hour | 500 hours | Roughly 3 person-months | A small mixed team working for a quarter |
| $120 / hour | 250 hours | Roughly 1.5 person-months | Senior people, and far less of them than the budget suggests |
| $200 / hour | 150 hours | Under a person-month | Consulting, not building. Almost never a whole product |
One budget hides a four-fold difference in hours, and none of it shows in a rate card. This is why the cheapest rate often produces the most expensive project. At $30 an hour you are buying people who need four times as long, and paying for the learning. It is also why a blended rate needs a second question. “Blended” means an average across the team, so a $60 blend covering one senior and three juniors is a different purchase from a $60 blend covering two mid-level engineers, and the first one will spend more of your hours on rework. Ask for the mix, not the average.
You cannot compare a fixed quote to an hourly estimate
This is the mistake that costs buyers the most money, and it is almost invisible while you are making it. Two proposals arrive. One says $30,000, fixed. The other says roughly 400 hours at $65, which is $26,000. The second looks like it saves $4,000.
It does not, because the two numbers are not the same kind of object. The fixed price is a commitment with a risk premium inside it. The estimate is a forecast with nothing inside it at all, and no obligation attached to being wrong. If the work runs to 520 hours, the fixed price is still $30,000 and the hourly engagement is now $33,800. The estimate was never the price; it was the optimistic end of a range that the contract lets the vendor move.
The fix is to make the two comparable before you compare them. Ask the hourly vendor to cap the number they have just estimated. A not-to-exceed cap keeps their flexibility and your ceiling, and ScienceSoft publishes it as a standard model because it is defensible for both sides. The answer is useful whichever way it goes. A vendor who caps at $30,000 has told you their estimate is real, and you can now read the two proposals side by side. A vendor who will not cap a scope they estimated last week has told you something more important: they do not trust the estimate either, and under their contract that uncertainty is yours.
The change-order clause is the real price
The headline number is what you compare. The change-order clause is what you actually pay. Every build changes, because a founder who learns nothing in eight weeks of watching their product get built has wasted the eight weeks, and the clause decides what learning costs. Most quotes handle this in a single vague sentence, which is a mistake, because there are three different situations underneath it.
| Situation | Weak clause | Strong clause | Ask this |
|---|---|---|---|
| You swap one thing for another of the same size | Billed as new work. The scope you dropped is not credited back | Absorbed inside the fixed price | “If I replace a screen with a different screen of the same size, what happens?” |
| You add scope | Absorbed silently, then discovered at the end as a delay, or billed at an unstated rate | Written up with its cost and its weeks, before any work starts, for you to accept or decline | “Show me the change-order clause and the rate that applies to it.” |
| The vendor discovers work nobody scoped | Billed to you, because the contract says the estimate was an estimate | Absorbed, because writing the scope was the vendor's job and they were paid for it | “Who pays for something neither of us thought of?” |
For reference, the terms we publish are that changes that swap one thing for another of the same size are absorbed inside the fixed price, and that changes that add scope are written up with their cost and weeks before any work starts, so the number only moves when you decide it should. The reason to write it that way is not generosity. It is that the first case is the one founders use constantly and the second is the one that should require a decision, and collapsing them into one clause means either you are billed for thinking or the vendor absorbs unlimited scope. Neither survives contact with a real project.
Whoever you buy from, get all three answers in writing before you compare headline numbers. Two quotes $5,000 apart with opposite change-order clauses are not $5,000 apart.
The payment schedule is a risk instrument, not admin
Payment terms get skimmed because they look like paperwork. They are the mechanism that decides how much leverage you hold at the moment you need it. Refuse one line in particular.
| Term | Weak | Strong | Why it matters |
|---|---|---|---|
| Deposit | 50% or more up front | A minority of the total, sized to the work before the first demo | A large deposit moves your leverage to the vendor on day one |
| Milestones tied to dates | “30% at week four” | Not used | A calendar date arrives whether or not the software does. It transfers no risk at all |
| Milestones tied to deliverables | “On completion of the design phase” | “On a signed-in build deployed to a URL you can open” | A phase can be declared complete. A deployed build cannot |
| Final payment | Released before handover | Released at handover, with the repository and accounts already yours | It is the only moment you have leverage over the handover itself |
The line to refuse is the milestone tied to a calendar date. “Thirty per cent at week four” sounds like a schedule and functions as an unconditional invoice, because week four arrives whether or not anything works. Replace every one of them with something you can open in a browser and sign in to. Our own published calendar puts a first deployed demo in week two of an eight-week build for exactly this reason: it is the earliest point at which a payment can be attached to evidence rather than to the passage of time.
A dedicated team is a staffing model wearing a pricing model’s clothes
The dedicated team model bills per person per month for capacity. You are not buying a product, an outcome or a date. You are renting people, and the vendor's obligation is discharged by the people showing up. That can be exactly right, but it changes what you have to supply.
The question that decides it is: who writes the backlog? Under fixed price and under time and materials, the vendor is accountable for turning your intent into work. Under a dedicated team, that job is usually yours, and if nobody on your side does it the team will fill the time anyway. So the true price is the monthly rate plus the product management you now have to provide, and that second number is real even though it never appears on an invoice. If you do not have someone in-house who can run a sprint, a dedicated team is the most expensive of the three models and the invoice will not tell you.
We do not sell this model. We don't sell staff augmentation or engineers by the month. That is a position rather than a judgement, and it exists because the studio is built to deliver a finished version rather than to hold seats. If capacity is what you need, the model is legitimate and you should buy it from someone who does it properly.
When a fixed price is the wrong thing to ask for
A fixed price is honest when the thing being bought has an edge: when it can be described, built and called finished. A first version has an edge, which is why we sell versions rather than projects. Plenty of work does not, and asking for a fixed price on it produces one of two bad outcomes. Either the vendor pads heavily to cover the unknown, and you pay for uncertainty you could have carried more cheaply yourself, or they price it thin and come back to renegotiate from a position where you cannot easily leave.
- Discovery and research, where the output is a decision and not a product. You are paying to find out what to build, and a price on that is a guess about a guess.
- Continuous product work after launch, where the backlog is reprioritised every fortnight. Fixed price makes changing your mind expensive, which is the opposite of what you want at that stage.
- Anything where you cannot say what “done” means. If the acceptance criteria would take longer to write than the feature, the model is fighting you.
- Integrations with a system nobody can see yet. A vendor pricing a black box will either pad heavily or come back to renegotiate, and both of those are worse for you than an hourly rate with a cap.
In all four cases the better instrument is time and materials with a cap and a short review cycle. You keep the ability to change direction, the vendor keeps the incentive to estimate honestly, and neither side has to pretend to know something they do not. If a studio that sells fixed prices tells you every situation calls for one, that is the sales page again.
Eight questions, and what each answer tells you
This is the part to take into a call. None of these require you to be technical, and the answers are more informative than the proposals they come with.
| Ask | What the answer tells you |
|---|---|
| What does this price assume? | A fixed price is only as good as the assumptions under it. A vendor who can list them has estimated. One who cannot has produced a number. |
| How many hours is this, and at what seniority mix? | Turns a rate into a shape. Two quotes at the same price can differ by a factor of four in the hours behind them. |
| Will you cap it? | The single most informative question to ask a time-and-materials vendor. Refusing to cap a scope they have just estimated says the estimate is not one they will stand behind. |
| What is the change-order clause? | Where most of the real difference between two similar quotes lives. Ask for it in writing, before you compare the headline numbers. |
| What would you cut to land in my band? | A vendor who names a trade-off has understood the constraint. One who fits everything in has thinned something without saying so, usually design QA, edge states or handover. |
| What are the milestones tied to? | Dates or deliverables. If it is dates, the payment schedule is doing no work for you. |
| Who is on this, and are they the people I met? | Rates are quoted for the people in the pitch and staffed with whoever is free. This question is uncomfortable on purpose. |
| What do I own, and when? | Repository, deployment accounts, design files, documentation. If ownership arrives at final payment rather than at first commit, the price has a lock-in inside it. |
A vendor who answers all eight without defensiveness is worth more than one whose number is ten per cent lower, because the eight answers are the ones that decide what the final invoice says.
How Kinetico prices, and why this model
One fixed price per scoped version. One 30-minute scoping call produces a written scope and a fixed price; you decide from there. The written scope, covering modules, screens, states, integrations and weeks, arrives within 5 working days. The published band is $15,000–$50,000 over 6–12 weeks, quoted as three tiers:
| Tier | Weeks | Price | Scope | What it proves |
|---|---|---|---|---|
| Lean | 6 | $15k – $22k | 1 user role · 6–10 screens · auth + one core workflow · 0–1 integration | Will anyone use the core loop at all? |
| Standard | 8 | $22k – $35k | 2 roles · 12–20 screens · core workflow + admin · payments or 2 integrations | Will they pay, and can you operate it? |
| Full | 10 – 12 | $35k – $50k | 3 roles · 20–30 screens · billing, notifications, reporting · 3+ integrations | Can this run as a business, not a demo? |
The tiers are published for a reason that helps you even if you buy elsewhere. Vendors map adjectives to their own tiers, so “a simple marketplace with payments” can be read as Lean at one studio and Full at another, and the same sentence comes back priced more than twice apart with every vendor being honest. Written as counts of roles, screens and integrations, it lands in the same tier everywhere. One role and six to ten screens is 6 weeks. Three roles, twenty to thirty screens, billing and three integrations is 10 – 12 weeks. Take the counts to whoever you are talking to.
The rest of the terms: You own the repository, deployment accounts, design files and documentation at handover, with no licence or lock-in. No retainer is required to keep the product running. We don't take $250k enterprise programmes — that isn't what the studio is built for. Scope drivers and what falls outside a version are on the pricing page, and what an eight-week build looks like week by week is on MVP development.
Questions
What are the software development pricing models?
Three, plus two variants. Fixed price is one number for a written scope, and the vendor absorbs the cost of its own estimate being wrong. Time and materials bills the hours worked, so you absorb it. A dedicated team bills per person per month for capacity rather than for an outcome, so you absorb it and supply the management as well. The variants are time and materials with a not-to-exceed cap, which is the honest middle, and outcome-based pricing, which is rare and hard to write down.
Is fixed price or time and materials better?
It depends on whether the thing being built has an edge. Fixed price is better when the scope can be written down and finished, which is true of a first version. Time and materials is better when the work is genuinely open-ended, as discovery, research and continuous product work after launch all are, because a fixed price on an unknowable scope is either padded heavily or renegotiated later. The trap is comparing them as numbers.
Why is a fixed price higher than an hourly estimate for the same work?
Because it contains a risk premium and the estimate does not. Under a fixed price the vendor pays for its own estimate errors, so the number covers the case where the work runs long. Under time and materials that case is billed to you when it happens. The premium is what you are buying, and a fixed price with no premium in it has either not been estimated or will be renegotiated.
What is a not-to-exceed cap?
A time-and-materials arrangement with a ceiling: you pay for hours actually worked, never more than an agreed maximum. You keep the flexibility, the vendor keeps the overrun risk. ScienceSoft publishes it as one of its standard models. It is the most useful thing to ask for when a vendor will only work hourly, and the answer is informative either way. A vendor who will not cap a scope they just estimated is telling you the estimate is not reliable.
What should a change-order clause say?
It should cover three situations, not one: swapping something of the same size, adding scope, and the vendor discovering work nobody scoped. Ours are published. Changes that swap one thing for another of the same size are absorbed inside the fixed price. Changes that add scope are written up with their cost and weeks before any work starts, so the number only moves when you decide it should. Ask for the clause in writing before you compare headline numbers. A number with an unlimited change-order rate behind it is not a fixed price.
How does Kinetico price software development?
One fixed price per scoped version, published as three tiers inside $15,000–$50,000 over 6–12 weeks. One 30-minute scoping call produces a written scope and a fixed price; you decide from there. The written scope arrives within 5 working days. We don't sell staff augmentation or engineers by the month. No retainer is required to keep the product running. You own the repository, deployment accounts, design files and documentation at handover, with no licence or lock-in. We use the model because a first version is a thing with an edge, which is the condition under which a fixed price is honest rather than a bet.
Method and sources
Written by Pukar Khanal and the Kinetico team, a product design and engineering studio in Pokhara, Nepal. We sell one of the models described here, which is stated in the opening and again in the section arguing against it. The three competitor positions were taken from pages fetched and read in full on 2026-09-09, not from search snippets: ScienceSoft (four models and the pricing-risk table, including the quoted passage on delaying deliverables under T&M), JayDevs (August 2025, four models plus pay-per-hire) and Apropo (August 2026, the “for IT agencies” framing, the margin sentence and the “fixed price is a bet” condition). All three also sell software development. The hour table is arithmetic on a $30,000 budget and the person-month figures assume a 160-hour month, rounded. The weak-versus-strong contract columns, the eight questions and the four cases where a fixed price is the wrong instrument are our recommendations from quoting builds, not measurements. Kinetico's figures are its published band, tiers, phase split and engagement terms, identical to the pricing page. No figure here is a measurement of a Kinetico engagement and no client is described.
Published 2026-09-09 · Last reviewed 2026-09-09 · Author: Pukar Khanal, Kinetico
Continue your research
Software Development Cost Breakdown →
Where the money goes inside a build, line by line, and the eight scope drivers that move the number.
Need comparable quotes?How to Write a Software Development RFP →
The ten facts a vendor needs to name a fixed price, and a one-page brief for builds under $50k.
Weighing vendors, not models?How to Choose a Software Development Company →
Seven criteria founders use, including how to read a pricing model as a signal about the vendor.
Want the number for your scope?Kinetico Pricing →
Three fixed tiers, $15k–$50k over 6–12 weeks, with what is and is not inside a version.
Bring the scope in counts of roles, screens and integrations to a 30-minute call and leave with a written scope and one fixed number. If your work is the kind this page says should be hourly, we will tell you that instead.
Related articles
Software Development Cost Breakdown 2026: Where the Money Goes in a Custom Build
Custom software development cost, line by line: published ranges from 5 guides, the phase split (engineering 50–60%, design 20–25%, QA 10–15%, scoping 5–10%), hourly rates by region, how fixed price vs time-and-materials moves the risk, the hidden lines (maintenance 15–25%/yr, DevOps, licences), and a worked $30k example.
How to Write a Software Development RFP (and When a One-Page Brief Gets You a Better Price)
The ten sections a software development RFP needs and what each one does to the quote that comes back; how to describe scope in roles, screens and integrations so a vendor can price it; why to state the budget as a band; RFP vs RFI vs RFQ vs scope of work vs statement of work; a one-page brief template for builds under $50k; how many vendors to send it to; the red flags in the proposals.
How to Choose a Software Development Company: 7 Criteria Founders Use
How to choose a software development company or partner: the 7 criteria that separate teams who ship from teams who delay, with the evaluation questions to ask and the red flags to walk away from.