Fixed Price vs Time and Materials for an MVP: 13 Clauses

The two models in one sentence each

Here is the difference before the details.

• Fixed price: you and the agency agree on a defined scope and one total price before work starts, and that price does not move unless you change the scope.
• Time and materials (T&M): you pay for the hours or days the team actually works, plus any tools or services, so the final cost depends on how long the work takes.

Fixed price vs time and materials: side by side

The two models compared point by point.

• Who carries the overrun risk. Fixed price: the agency. Time and materials: you.
• Total cost known before you start. Fixed price: yes. Time and materials: no, only an estimate.
• Flexibility during the build. Fixed price: low, changes go through a change request. Time and materials: high, you can reprioritise every week.
• What you need before signing. Fixed price: a clear scope, with screens, flows and integrations. Time and materials: a rough backlog and a weekly budget cap.
• Your time spent managing. Fixed price: low. Time and materials: higher, you review hours and priorities.
• Best for. Fixed price: a first MVP with one core flow. Time and materials: iteration after launch, open research.
• Main risk. Fixed price: vague scope that leads to disputes. Time and materials: a bill that keeps growing.

When fixed price is the right choice

Fixed price fits when you can describe your MVP in a few sentences. For example: users sign up, create a profile, book a session with a coach and pay by card. That is one core loop with known screens and known integrations. An agency can price it with confidence. It also fits when:

• You have a set budget, from savings or a small round, and cannot absorb a surprise.
• You need a demo date, for investors or a launch event.
• You are not technical and cannot judge whether 40 hours on a feature is fair. That last point matters most for non technical founders. With T&M, you are buying hours you cannot check. With fixed price, you are buying an outcome you can test on your own phone.

When time and materials is the right choice

T&M is a better fit when the scope cannot be written down yet. If you choose T&M, cap it. A weekly or monthly budget ceiling turns an open bill into a controlled one. T&M fits:

• Research work, like testing whether an AI model can do a task reliably.
• Ongoing improvements after launch, when priorities change every week based on user feedback.
• Large systems with many unknown integrations, where any fixed quote would be padded to cover the risk.

Clauses for a fixed price contract

These are the clauses that decide whether a contract actually protects you. Ask for them in writing, whichever model you choose. These are examples to discuss, not legal advice. Have a lawyer review the final contract.

• 1. Scope annex. "The scope is defined in Annex A, which lists every screen, user flow, integration and platform included. Anything not listed is out of scope." Why: most fixed price disputes start with a scope that says "user management" instead of naming each screen.
• 2. Change request process. "Any change to Annex A is quoted in writing before work starts. No change is billed without the client's written approval." Why: this stops surprise invoices at the end of the project.
• 3. Delivery date. "The agency delivers the build described in Annex A by a named calendar date, provided the client supplies content and feedback within the agreed review times." Why: "about 3 months" is not a date. The second half is fair to both sides and stops blame later.
• 4. Acceptance criteria. "The build is accepted when each flow in Annex A works as described on iOS and Android test devices. The client has a set number of days to report defects." Why: it defines "done" before the argument starts.
• 5. No separate paid discovery. "The fixed price is the total for Annex A. No separate discovery fee is charged before or on top of it." Why: some quotes add a separate paid discovery phase before the "fixed" price applies. Ask whether that is the case.

Clauses for a time and materials contract

If you choose T&M, ask for these three in writing.

• 6. Budget cap. "Total billing will not exceed an agreed amount per month without the client's written approval."
• 7. Itemised timesheets. "Invoices list hours per person, per task, per week." Why: if you cannot see where the hours went, you cannot manage them.
• 8. Rate lock. "Hourly or daily rates stay the same for the duration of the contract."

Clauses for both models

These apply whichever contract you sign.

• 9. Code and IP ownership. "All source code, designs and accounts created for the project belong to the client. The repository is held in, or transferred to, the client's GitHub account." Why: without this, changing agency later can mean starting again.
• 10. Store accounts in your name. "The App Store and Google Play developer accounts are registered to the client." Why: if the app is published under the agency's account, moving it later is slow and depends on their cooperation.
• 11. Bug fix period. "The agency fixes defects in the delivered scope at no extra cost for a defined period after launch." Why: bugs show up once real users arrive. This clause says who pays.
• 12. Handover. "On delivery or termination, the agency provides the code, credentials, environment setup and documentation needed for another team to continue." Why: this is your protection if the agency disappears or you outgrow it.
• 13. Termination. "Either party can end the contract with written notice. The client pays for work delivered to date and receives everything produced up to that point."

Red flags in either contract

Want to check a contract against the 13 clauses above? Book a call and bring it with you. For the broader checklist on choosing a partner, see our articles on how to hire an MVP agency. If you want to know which features push a quote up, our feature cost breakdowns cover them one by one. Watch for these signs in any contract:

• The scope is one paragraph long with no list of screens.
• No delivery date, only a duration "from kickoff", with no defined kickoff.
• Fixed price on paper, with "estimated" written next to the total.
• The agency keeps the code until a final payment you did not agree to.
• Changes are "billed at our standard rate" with no requirement to quote first.
• No mention of who owns the App Store and Google Play accounts.

A practical approach: fixed price first, T&M later

Many founders do best with both models in sequence. Build the first version on a fixed price with a tight scope. Launch, watch what users do, then move to a capped T&M or monthly support plan for the next round of changes. For that first version, the MVP development package is a fixed price, from $3,460, delivered in 21 days. It covers iOS and Android from one Expo project, auth, onboarding and your core loop, with TestFlight and Play submission support. You get 100% of the source code and two weeks of fixes after delivery. The scope is written before we start. Fixed price, no discovery fees. If you are comparing quotes now, book a call. The call is free, and you get a fixed quote.

Is fixed price always cheaper than time and materials?

No. A fixed quote can include a buffer for risk, so on paper it may look higher than a T&M estimate. The difference is that the fixed price is the final number, while the T&M estimate is a starting point. For a defined MVP, the fixed total is usually easier to plan around.

Can I change features during a fixed price project?

Yes, through a change request. The agency quotes the change in writing and you approve it before work starts. Ask how changes are handled before you sign, not halfway through the build.

What happens if a fixed price project runs late?

That depends on the contract. Ask for a delivery date in writing and a clause that says what happens if it slips. In a generic contract, that could be the agency finishing the agreed scope without billing more. Also check the client side of the clause: late feedback or content from you can move the date.

Who should own the code in an MVP contract?

You should. The contract should state that all code, designs and accounts belong to you, that the repository sits in your GitHub, and that the store developer accounts are in your name.