Fixed Price vs Time and Materials: Which Contract for Your Software or MVP?

The Three Ways to Pay for Software

Almost every software quote uses one of three models, or a mix of them:

• Fixed price. One price for an agreed scope, agreed before work starts. If the work takes longer, the developer pays for the extra time.
• Time and materials (T&M), or hourly. You pay an agreed rate for the hours worked, plus any costs such as paid services. The estimate is a forecast, not a promise.
• Retainer. A fixed monthly fee for a set amount of capacity, such as a number of hours, with the work chosen month by month.

Who Carries the Risk

The real difference is not the invoice format. It is who pays when the estimate is wrong, and software estimates are often wrong. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27%. That average hides a long tail: one in six projects overran by 200% on average, with schedule overruns of almost 70%. Those figures measure how far real costs landed from budgets. They do not tell you which contract type is better, but they do tell you how much is at stake when you decide who carries the overrun.

The US government's procurement rules, the Federal Acquisition Regulation (FAR), describe the trade-off plainly, and the logic applies to any buyer:

• A firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs". It fits when performance uncertainties can be identified and their cost reasonably estimated.
• A time-and-materials contract "provides no positive profit incentive to the contractor for cost control or labor efficiency". The FAR allows it only when the extent or duration of the work cannot be estimated with reasonable confidence, and requires a ceiling price that the contractor exceeds at its own risk.

Put simply: under fixed price, a slow week costs the developer. Under hourly, a slow week costs you. Neither is dishonest. They just put the same risk on different people, and the person carrying it will price it in or manage it.

One Project, Priced Three Ways

Here is the same project quoted hourly and fixed price, then run through different outcomes. The rate and hours are assumptions chosen to keep the arithmetic easy. Swap in the numbers from your own quotes; the shape of the result stays the same.

The project: a B2B booking tool with sign-up, one booking workflow, subscription billing, teams and roles, a Google Calendar integration and an admin view.

Assumptions: the developer estimates 300 hours at $75 an hour.

• Hourly estimate: 300 × $75 = $22,500, with the final bill depending on hours actually worked.
• Fixed quote: the developer adds a 20% contingency for the risk it is taking on: $22,500 × 1.20 = $27,000, whatever the hours.

Break-even hours = fixed price ÷ hourly rate = $27,000 ÷ $75 = 360 hours, which is 20% over the 300-hour estimate. The 27% and 200% rows apply the overruns from the IT project study above to this example; they illustrate the risk, they do not predict it.

Three things fall out of this table:

1. Fixed price is a bet that the work will overrun by more than the contingency. With a 20% contingency, you are better off hourly unless the work runs more than 20% over. If you trust the estimate and can watch the hours, hourly is cheaper on average.
2. Hourly has no ceiling. The bottom rows are where budgets break. If you have a hard limit, such as a grant or the money left from a pre-seed round, the downside matters more than the average.
3. The bottom rows hurt the fixed-price developer too. At 600 hours its cost is 600 × $75 = $45,000 against $27,000 of income, an $18,000 loss. That is where the corner-cutting and scope arguments described above come from. Ask how the developer arrived at its number.

A common middle path is hourly with a cap: you pay for hours worked up to an agreed ceiling, say $27,000, and the developer absorbs anything above it. You keep the savings if the work comes in early, and the developer still carries the tail risk. Expect the hourly rate or the cap to be a little higher to pay for that.

For reference, the same scope on our published price list is a $5,000 base plus subscription billing (+$1,000), teams and roles (+$1,500) and one integration (+$750): $8,250 fixed, delivered in 30 days or less. Your quotes will differ; the table is about the shape of the risk, not the rate. For typical market ranges by type of provider, see our MVP development cost guide.

How Scope and Change Requests Work

Every project learns something in the middle. The models differ in what happens next.

Under hourly, you redirect the hours. Ask for a CSV export halfway through and, if it takes 16 hours, the bill grows by 16 × $75 = $1,200 and the finish date moves. Nobody needs to sign anything, which is the strength and the danger: ten small "while you're in there" requests add up the same way, without anyone deciding to spend the money.

Under fixed price, new work goes through a change request. A good process looks like this:

1. You describe the change in writing.
2. The developer replies with the extra cost and the new delivery date, for example 16 hours at the contingency rate: 16 × $75 × 1.20 = $1,440, and two more working days.
3. You approve it, drop it, or swap it for something of similar size already in scope.
4. Only then does work start.

The hard part is the line between a clarification (how something already in scope should behave) and a change (something new). A scope written as user actions, such as "an admin can invite a teammate by email and set them as viewer or editor", leaves less room for argument than a scope written as headings, such as "user management".

For an MVP, the cheapest answer to most mid-build ideas is "after launch". Real users will tell you which of them matter. Our guide to building an MVP step by step covers how to cut scope before you pay for it.

Milestone Payments

Payment schedules are how you manage the risk the price model leaves with you. The rule: pay for working software you have accepted, not for time passing or documents delivered.

For the $27,000 fixed quote above, a four-stage schedule could be:

Under hourly, the equivalent control is invoicing every week or two with timesheets broken down by task, plus a cap per milestone. If the core workflow is estimated at 120 hours, agree that the developer stops and tells you before billing hour 121.

Short projects need fewer milestones. A 30-day build split into four payments spends more time on invoices than on software; two payments with a strong delivery guarantee does the same job. That is the structure we use, described below.

Retainers: The Third Model

Once a product is live, the work stops being a project with an end. It becomes a stream: a feature this week, a billing fix next week, an onboarding test the week after. Fixed price fits that badly, because every small piece needs its own quote and sign-off. Pure hourly fits it better but gives no guarantee the developer has time for you when something breaks.

A retainer buys reserved capacity. Our Growth Partner retainer, for example, is from $5,000 a month for 60 hours of senior development, billed monthly in advance, month to month with 7 days notice to pause or cancel. Unused hours do not roll over. That last point changes your real hourly cost:

• All 60 hours used: $5,000 ÷ 60 = $83.33 an hour.
• 48 hours used: $5,000 ÷ 48 = $104.17 an hour.

So a retainer is good value when you have a steady backlog and someone on your side who ranks it every week. It is poor value if you need ten hours one month and none the next; plain hourly is cheaper for that. Our SaaS development partner guide compares a retainer with hiring in-house.

Which Model Fits Your Project

Many products use all three in turn: hourly to answer an unknown, fixed price to build the first version, then a retainer once it is live.

What to Put in the Contract

This section is general guidance for buyers, not legal advice; have a lawyer review any contract you sign. Whatever the pricing model, these clauses decide whether it works:

1. Scope. What will be built, written as things a user can do, plus a short list of what is not included. For hourly work, a backlog and an estimate per item.
2. Acceptance criteria. How you will check each delivery, how long you have to test it (five working days is common), and what counts as a defect (it does not do what the scope says) versus a change (you now want something different).
3. Change process. Changes requested in writing, priced and dated in writing, approved before work starts. Under hourly, a threshold above which the developer must ask before spending hours.
4. Payment schedule. Tied to accepted milestones for fixed price; weekly or fortnightly timesheets and a cap for hourly.
5. Intellectual property. A written assignment of the code and designs to you, when it happens (on signing, per milestone or on final payment), a list of open-source and third-party components and their licences, and the code repository and hosting accounts in your name.
6. Warranty or bug-fix period. How long after launch the developer fixes defects at no charge, what counts as a defect, and how fast they respond.
7. Delivery date and what happens if it slips. A date without a consequence is a hope.
8. Termination. What you receive and what you owe if either side stops halfway, including the code written so far.

The IP clause deserves extra care, because paying for code does not by itself make you its owner. UK government guidance says that when you commission a work, the first owner of copyright is the person or organisation that created it, unless you agree otherwise in writing, and that a freelancer usually keeps copyright in what they produce unless the contract says otherwise. Under US law, copyright belongs to the author unless it is a "work made for hire", and computer programs are not among the nine kinds of commissioned work that can be made for hire by agreement. A transfer of copyright must be in writing and signed. None of this depends on whether you paid by the hour or a fixed price, so check the clause either way.

Red Flags in Quotes

• A fixed price with no written scope. A fixed price for a vague scope means the developer decides what the price buys.
• An hourly quote with no estimate, no cap and no timesheets. You carry all the overrun risk and cannot see it building up.
• "Unlimited revisions" or "unlimited changes" at a fixed price. Either the price is padded to cover it, or the promise will be argued down later.
• No change process. Every disagreement about scope will be settled by whoever is more stubborn.
• Everything paid upfront. You lose your leverage before you have seen working software.
• A licence instead of an assignment, or code kept in the developer's accounts until the end with no access for you while it is built.
• No bug-fix period, or "support" that is never defined.
• A delivery date with no consequence if it is missed.
• A quote far below the others with no explanation of scope. The difference is usually in what is left out. Line the quotes up feature by feature before comparing totals. Our guide to choosing an MVP development company lists questions to ask.

How minidev.pro Uses Both

We use fixed price for building an MVP and a monthly retainer for ongoing work on a live product, because those are the two situations where each model fits. These are the terms as our terms of service, price list and SaaS development page state them.

MVPs: fixed price.

• From $5,000 fixed for a focused web MVP: sign-up, one core workflow, database, Stripe checkout or a waitlist, a basic admin view, a landing page, deployment and 30 days of support. Add-ons such as subscription billing (+$1,000) or AI features (+$2,500) have published prices.
• Scope is agreed before the project starts. Major scope changes may affect timeline and pricing; otherwise the fixed price does not change.
• Payment is 50% upfront and 50% on delivery.
• Standard delivery is 30 days from project start. If the MVP is not delivered within the agreed timeframe, and the delay was not caused by scope changes you asked for, you get a full refund of fees paid plus $2,000.
• 30 days of post-launch bug fixes are included, and we warrant that the work will meet the agreed specifications.
• On full payment, all custom code and deliverables become your property, with full source code and documentation. Open-source components stay under their own licences.

Live products: the Growth Partner retainer. From $5,000 a month for 60 hours of senior development, billed monthly in advance, typically 2 to 3 features a month plus bug fixes and performance work. Unused hours do not roll over, extra hours are available at an agreed hourly rate, and you can pause or cancel with 7 days notice. Schedullr, for example, was built as an MVP and then had ongoing SaaS engineering on its Notion and LinkedIn integrations; see the Schedullr case study.

If you are not sure what your MVP would cost, the MVP cost calculator gives a range in a few minutes, and a call turns it into a fixed quote.

When We Are Not the Right Choice

Our fixed-price model needs a scope that can be written down and built in 30 days or less. It is a poor fit for open-ended research where nobody knows yet whether the task can be done; pay someone by the hour, in short capped blocks, until the answer is clear. It is also a poor fit if you want developers billed hourly inside a team you manage, if you need only a few hours of work a month (our retainer starts at 60), or if you are running a large enterprise tender that needs 50 or more engineers. And we do not build consumer mobile games.

It fits when you can describe the first version on a page or two, want to know the price and the date before you start, and want the developer, not you, to carry the risk of being late.

Frequently Asked Questions

Is fixed price or hourly cheaper for software development?

Neither is cheaper by default. A fixed quote usually includes a contingency for the risk the vendor takes on, so if the work goes exactly to plan, hourly costs less. If the work runs over, fixed price costs less because the vendor absorbs the overrun. In our worked example a 20% contingency makes hourly cheaper until the work runs 20% over the estimate, and fixed price cheaper after that.

When is time and materials better than fixed price?

When the scope cannot honestly be written down yet: research, a proof of concept where nobody knows if the task can be done, work on an existing codebase nobody has reviewed, or small, occasional tasks. It also suits developers who join a team you manage day to day. Add a not-to-exceed cap and weekly timesheets so the budget cannot drift unseen.

What happens if I want changes during a fixed-price project?

Small clarifications inside the agreed scope should be absorbed. New features go through a change request: the vendor states the extra cost and the effect on the delivery date in writing, and work starts only after you agree. If a contract has no written change process, expect arguments about what counts as a change.

Do fixed-price quotes include padding?

Usually, and that is fair: the vendor is taking the risk that the work runs over, and a contingency pays for that risk. What matters is whether the scope behind the number is written down, so you know what the price buys. A fixed price for a vague scope protects nobody.

What should a fixed-price software development contract include?

A written scope, acceptance criteria with a time window to test each delivery, a change request process, a payment schedule tied to accepted work, a written assignment of intellectual property to you, a bug-fix or warranty period, and what happens if either side ends the contract early. This is general guidance, not legal advice.

Who owns the code if I pay a developer by the hour?

Paying for the work does not by itself make you the owner. Under UK and US copyright law, a contractor generally owns what it creates unless ownership is transferred in writing, and US law requires the transfer to be signed. The pricing model makes no difference, so check the IP clause in any contract, fixed or hourly.

How does minidev.pro charge?

MVPs are fixed price from $5,000, delivered in 30 days or less, paid 50% upfront and 50% on delivery. If we miss the agreed timeframe and the delay was not caused by scope changes you asked for, you get a full refund of fees paid plus $2,000. Ongoing work on a live product is the Growth Partner retainer, from $5,000 a month for 60 hours, month to month with 7 days notice.

Sources

All sources checked October 2026. Statutes and regulations are amended from time to time; check the current text before relying on it.

• Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project May Be Riskier Than You Think", Harvard Business Review, September 2011 (1,471 IT projects, 27% average cost overrun, one in six with a 200% average cost overrun and almost 70% schedule overrun): hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think; open-access version: arxiv.org/abs/1304.0265
• Federal Acquisition Regulation 16.202-1, Firm-fixed-price contracts (risk and responsibility for costs): acquisition.gov/far/16.202-1
• Federal Acquisition Regulation 16.202-2, Application of firm-fixed-price contracts (when they are suitable): acquisition.gov/far/16.202-2
• Federal Acquisition Regulation 16.601, Time-and-materials contracts (no positive profit incentive, when they may be used, ceiling price): acquisition.gov/far/16.601
• UK Intellectual Property Office, Ownership of copyright works (commissioned works and freelancers): gov.uk/guidance/ownership-of-copyright-works
• 17 U.S.C. § 101, definition of "work made for hire": law.cornell.edu/uscode/text/17/101
• 17 U.S.C. § 201, ownership of copyright: law.cornell.edu/uscode/text/17/201
• 17 U.S.C. § 204, transfers of copyright ownership must be in writing and signed: law.cornell.edu/uscode/text/17/204
• minidev.pro, Terms of service (MVP, retainer, payment, IP and warranty terms): minidev.pro/terms
• minidev.pro, MVP cost calculator price list: minidev.pro/mvp-cost-calculator
• minidev.pro, SaaS development (Growth Partner retainer terms): minidev.pro/saas-development

---