Fixed price vs time and material: which contract protects you when buying a website, app or software?

Fixed price vs time and material: the two models explained

In a fixed-price contract, the developer agrees to deliver a defined scope for an agreed total; in a time and material (T&M) contract, the buyer pays for the hours actually worked and any costs incurred, at agreed rates. Everything else in the fixed price vs time and material debate follows from that difference in who carries the risk of the work taking longer than expected.

With a fixed price, the developer carries that risk. If the job takes twice as long, the buyer still pays the agreed amount, provided the scope has not changed. To protect themselves, developers price in a buffer, insist on detailed specifications and treat anything new as a paid change request.

With time and material, the buyer carries the risk. If the job takes twice as long, the bill doubles. In return, the buyer can change direction freely, reorder priorities and stop at any point, paying only for what was done.

There are useful middle grounds: capped time and material, where hours are billed up to an agreed ceiling, and fixed price per milestone, where a large project is broken into smaller fixed pieces. Most well-run projects in practice use one of these rather than a pure form of either model.

Which contract model protects the buyer better?

Fixed price protects you better when you can describe the finished product precisely; time and material protects you better when you cannot, because a fixed total on unclear scope gets padded, disputed or quietly cut. In fixed price vs time and material, the model that protects the buyer is the one that matches how much is known.

A fixed price feels safer because the number is known. But that safety depends entirely on the scope document. If it says “user dashboard” without describing what the dashboard shows, the developer will build the smallest thing that fits the words, and you will pay extra for what you actually meant. The protection is only as strong as the specification.

Time and material feels riskier because the total is open. But it rewards buyers who stay involved: you see progress weekly, can drop a feature that turns out unnecessary, and never pay a buffer for risks that do not happen.

So ask yourself honestly: could you write down every screen, rule and integration today, and would you still want the same things in two months? If yes, a fixed price with tight scope protects you. If no, choose capped time and material or phased fixed pricing, and put your effort into visibility and control rather than a thicker contract.

What is scope creep, and how does each model handle it?

Scope creep is the gradual growth of a project beyond what was agreed, one reasonable-sounding request at a time. “Can we add a second language?” “Could customers also upload documents?” Each is small; together they can add weeks, and it is the real test of fixed price vs time and material.

In a fixed-price contract, scope creep turns into friction. The developer either absorbs extra work, which squeezes quality elsewhere, or raises a change request that the buyer sees as nickel-and-diming. Disputes often come down to whether something was “obviously included” in the original wording.

In time and material, scope creep turns into a bigger bill. Nobody argues about whether something was included, because everything is billable, but budgets drift unless someone tracks what each addition costs.

The cure is the same in both models: write down every addition, estimate it, and decide consciously whether it goes in now, later or never. We list each new request as a separate line with its price and schedule impact, and nothing is built or billed until you approve it in writing. That keeps the original scope clean and makes every decision visible.

The Agile Manifesto puts the tension neatly, valuing “customer collaboration over contract negotiation” and “responding to change over following a plan”. A good contract supports that collaboration instead of fighting it.

How should change requests work in a software contract?

A sound change request process has four steps: the request is written down, the developer estimates cost and time, the buyer approves or declines in writing, and only then is the work scheduled. It works on both sides of fixed price vs time and material and is the single best protection against budget surprises.

Put the process in the contract, not just in good intentions. It should say who can request changes on your side (ideally one named person), how quickly the developer will estimate them, and how approved changes affect the schedule and payment milestones.

Also agree what does not count as a change: fixing bugs in agreed features, making the product match the agreed designs, and small wording or image swaps. Without that line, every minor fix becomes a negotiation.

A practical format is a simple shared list with columns for the request, the date, the estimate, the decision and the target release. For our clients that list lives in the same WhatsApp and document trail as the quote, so anyone can see what was approved and when.

• Sample clause: “Any change to the agreed scope will be estimated in writing within [n] working days and will not be performed or invoiced without the Client’s written approval.”
• Sample clause: “Correction of defects in agreed features is not a change and is carried out at no additional charge.”
• Sample clause: “Approved changes will be added to the schedule with a revised delivery date stated in the approval.”

When does fixed price become risky for the buyer?

A fixed price becomes risky when scope is vague, when the project involves unknown code or integrations, or when the price is so low that the developer can only make it work by cutting corners. In those cases the certainty you think you bought is not real, and fixed price vs time and material tips towards flexibility.

Vague scope is the most common trap. A one-page brief for a marketplace app, signed at a set total, almost guarantees disagreement later. The developer will interpret every gap narrowly; you will interpret it generously. Someone ends up unhappy, and often the project stalls.

Unknowns are the second trap: integrating with an old ERP whose API nobody has documented, rescuing half-finished code from another developer, or automating a process that is not yet written down. A developer who gives a set total without looking first is guessing, and guesses usually get recovered later through change requests or reduced quality.

The third trap is an unrealistically low bid. If one quote is far below the others for the same scope, ask what has been left out. Missing testing, no admin panel, template-based design or developer-owned accounts are common explanations.

Finally, beware long fixed-price contracts with most of the payment upfront. If the developer disappears halfway, recovering money is hard. Our page on what to do when a developer left the project midway covers that situation.

When is time and material the better choice?

Time and material is the better choice when requirements will be discovered along the way: new products, MVPs, research-heavy AI work, integrations with unknown systems and ongoing improvements after launch. In these projects, paying a buffer for a fixed total buys little real protection, so fixed price vs time and material usually favours T&M.

The GOV.UK Service Manual describes agile teams planning continuously and reviewing plans regularly based on progress and any new facts and requirements. That way of working fits time and material naturally, because the plan is expected to change as the team learns.

T&M also suits work that is ongoing by nature: monthly maintenance, SEO, feature releases after launch and support. Here the question is not “what is the total?” but “what did we get for this month?”, answered by a clear task list.

The buyer’s protection in T&M comes from visibility, not from the contract total. Ask for a weekly summary of hours by task, access to test builds or preview links, a prioritised backlog you control, and the right to stop at any point after paying for work done. Adding a cap, covered next, protects the budget as well.

What is capped time and material (not-to-exceed)?

Capped time and material bills actual hours at agreed rates but sets a maximum total that cannot be exceeded without the buyer’s written approval. It is often the fairest answer to fixed price vs time and material when scope is partly known.

You get the honesty of T&M: if the work goes faster, you pay less. You also get a ceiling on exposure: if it goes slower, the developer must stop and ask before crossing the cap. That conversation happens early, with evidence of where the hours went, rather than as a surprise invoice.

Caps work best with a warning threshold. For example, the developer notifies you when 75% of the capped hours are used, with a forecast of what remains. You can then drop lower-priority features, raise the cap for specific items, or stop.

Be clear about what the cap covers: which features, which phase, and whether bug fixes on delivered work count towards it. A cap on an undefined scope is just a budget; a cap tied to a prioritised feature list is real protection.

• Sample clause: “Total fees for Phase 1 shall not exceed [cap] without the Client’s prior written approval.”
• Sample clause: “The Developer will notify the Client in writing when 75% of the cap has been used, with an estimate to complete.”
• Sample clause: “Time records by task will be shared weekly.”

Milestone payments: tying money to visible progress

Milestone payments link each payment to something you can see and check, such as approved designs, a working test build or a launched product, so money never runs far ahead of delivered work. They work on either side of fixed price vs time and material, including capped T&M.

A good milestone is observable. “Backend 50% done” is not; “admin panel live on a test link with product entry and order list working” is. You should be able to open, click and confirm each milestone yourself, without taking the developer’s word for it.

Keep the first payment modest relative to the whole, enough to show commitment and cover early design work. Spread the rest across real deliverables, and keep a meaningful share until launch and acceptance.

For apps, natural milestones are approved screen designs, a first test build on your phone, a feature-complete build, and live store listings. For websites: approved home page design, full preview, and launch. How the payments are split for your project is set out in your written quote; the principle is that each payment follows evidence.

Payments in India are by UPI or bank transfer, and international clients pay by Wise, bank wire or PayPal, quoted in USD. Our terms and refund policy explain the general rules.

Fixed price vs time and material for a website

For most business websites and online stores, an itemised fixed scope works well, because pages, templates, forms and features can be listed precisely before work starts. When a website owner weighs fixed price vs time and material, the main risks are content and revision rounds, not unknown engineering.

Write down the pages or page templates, the number of revision rounds, who supplies the text and photos, which integrations are included (WhatsApp, booking, payment gateway, CRM) and what counts as launch. With that, a set total is fair to both sides.

Where websites drift is in content and design changes after approval. A clause that says design direction is approved at a set point, and that changes to an approved direction are handled as change requests, keeps the project honest.

Large SEO sites sit in between. The build is predictable, but the number of pages and the depth of content per page can grow as research reveals more opportunities. Fix the page count and template set in the quote, and treat additional batches of pages as separate items.

Our websites start at ₹10,000 for a static site of up to 100 pages and ₹20,000 for a 299+ page SEO site. Timelines are explained on how long it takes to build a website.

Fixed price vs time and material for apps and custom software

For apps and custom software, a phased approach usually protects the buyer best: a small paid discovery, a tightly scoped MVP priced in full, then smaller releases or capped time and material for what follows. Trying to fix the price of a whole product up front is where most disputes begin.

Discovery turns an idea into user roles, screens, rules and integrations. Its output is useful even if you take it to another developer. With that in hand, the MVP can be itemised screen by screen with honest estimates.

After launch, real users change priorities. Features you were sure about get dropped; things nobody predicted become urgent. That is exactly the situation fixed price handles badly and T&M handles well, so moving to capped releases at this point is natural.

Integration-heavy software, such as connections to Tally, an ERP or a government API, deserves special care. Estimate the integration after a short technical check, not before. The difference between a documented API and an undocumented one can be weeks.

Our apps start at ₹40,000 and custom software at ₹60,000. For schedules, see how long it takes to build an app; for founders buying software for the first time, hiring a developer as a non-technical founder is a good companion read.

Hybrid contract models that combine fixed price and time and material

Most successful software contracts are hybrids: fixed where things are known, flexible where they are not. Choosing between fixed price vs time and material does not have to be all or nothing.

Fixed discovery, then T&M build. A short, fixed-price discovery produces a plan; the build runs on capped T&M against that plan. You see the thinking before committing to the full budget.

Fixed price per milestone. The project is split into phases, each priced separately once the previous one is done. You get budget certainty for the next few weeks, not a guess about the next six months.

Fixed core, T&M extras. The agreed scope is priced as a total; anything added later is billed by time at agreed rates. This works well when the core is clear but you expect ideas during the build.

Monthly retainer with a task list. For ongoing work, a monthly fee covers an agreed set of tasks or hours, reviewed each month. Maintenance and SEO often run this way.

Whichever mix you choose, the same principles apply: clear acceptance criteria, written approval for changes, visible progress, and payments that follow evidence.

Acceptance criteria: the clause that decides what “done” means

Acceptance criteria describe, in testable terms, what each feature must do to be considered complete, and they matter more than the pricing model itself. Most contract disputes, whatever side of fixed price vs time and material you chose, are really disputes about whether something is finished.

Good criteria are specific and checkable: “A customer can book a slot, pay by UPI, receive a confirmation on WhatsApp and see the booking in the admin panel within one minute.” Weak criteria are subjective: “booking works properly” or “the app is user-friendly”.

The contract should also set an acceptance window, a period in which you test a delivered milestone and either accept it or list specific defects. Without a window, milestones can stay open indefinitely; with one that is too short, you may accept something you have not properly checked.

Separate defects from changes. A defect is where the product does not meet the written criteria; fixing it is part of the original work. A change is where you want it to do something different; that follows the change request process.

• Sample clause: “A milestone is accepted when the Client confirms in writing, or when [n] working days pass after delivery without a written list of defects.”
• Sample clause: “Defects against the written acceptance criteria will be corrected without additional charge.”

Sample clauses to ask for in any software contract

Whatever the pricing model, a buyer should see clauses on scope, changes, acceptance, payments, ownership, access and exit. The samples on this page are starting points to discuss, not legal drafting; have your own lawyer review anything significant before signing.

Ownership deserves special attention. The contract should state that the code, designs and content created for you belong to you once paid for, and that domains, hosting, app store accounts and third-party services are registered in your name. Access to these should never depend on the developer’s goodwill.

Exit terms protect both sides. If either party ends the engagement, what is paid for, what is handed over and how quickly? A clean exit clause makes it far easier to continue with someone else if things go wrong.

• Scope: an itemised list or document attached to the contract, with version and date
• Change control: estimate in writing, approval in writing, no work or billing before approval
• Acceptance: testable criteria and an acceptance window per milestone
• Payments: each tied to a specific, observable milestone
• Ownership: code, content and designs transfer to the client on payment
• Accounts: domain, hosting, app store and API accounts in the client’s name
• Handover: source code repository access and deployment notes at each milestone
• Exit: work paid for is handed over within an agreed period if either side ends the contract

Red flags in fixed-price and time-and-material proposals

The biggest red flags are the same in both models: vague scope, heavy upfront payment, no visible progress and accounts in the developer’s name. Picking the right side of fixed price vs time and material rarely rescues a weak proposal.

In fixed-price proposals, watch for a total with no itemised scope, a promise to build “everything you need” without a feature list, no change request process, and a price far below comparable quotes. Each suggests the real negotiation will happen later, when you have less bargaining power.

In time-and-material proposals, watch for no cap or estimate at all, no weekly reporting, hourly records that cannot be tied to tasks, and resistance to showing work in progress. Open-ended billing without visibility is where budgets disappear.

In either, be cautious if the developer will not put terms in writing, cannot say who will do the work, or plans to publish your app under their own store account. Quotes across the market vary widely for the same brief; the difference usually lies in scope assumptions, testing, design and ownership rather than in skill alone. Our guides to freelancer vs agency for a website and app development company vs freelancer cover who to hire.

Worked example: one hypothetical client portal under both models

This hypothetical example compares how the same project could run under fixed price vs time and material. Say a chartered accountancy practice in Ahmedabad wants a client portal: clients upload documents, see filing status, download reports and receive reminders on WhatsApp. Staff manage tasks from an admin panel.

Under a pure fixed price, the developer asks for a detailed specification. The firm writes four pages; half the rules about which staff see which clients are left vague. The bid includes a sizeable buffer. Mid-build, the firm realises it also needs bulk uploads and GST-specific status stages. Both become change requests, the relationship gets tense, and the final cost ends up above the original bid anyway.

Under a phased approach with capped T&M, a short discovery maps user roles, statuses and permissions. Phase one (login, uploads, status, reminders) is priced in full and delivered in about six weeks. Phase two (bulk uploads, reports, GST stages) runs on capped T&M with weekly summaries. The firm drops one planned report after seeing how clients actually use the portal, saving hours it would have paid for under a fixed total.

Neither side of fixed price vs time and material is free of effort. The fixed route needed a far better specification up front; the phased route needed the firm’s partner to review progress every week. The right choice depends on which of those your business can realistically provide. Custom software of this kind starts at ₹60,000.

Checklist before you sign: fixed price vs time and material

Use this checklist to choose between fixed price vs time and material and to check the contract before signing. If you cannot tick most items, clarify them first; it costs far less to fix a contract than a project.

Share the checklist with each developer you are comparing. How they respond, openly or defensively, tells you a lot about how the project will go.

• Can you describe every screen, rule and integration today? If not, prefer phased or capped T&M
• Is the scope itemised and attached to the contract?
• Is there a written change request process with approval before work or billing?
• Are acceptance criteria testable, with an acceptance window?
• Is each payment tied to a milestone you can see and check?
• For T&M: is there a cap, a warning threshold and weekly time records by task?
• Are code, domain, hosting and store accounts in your name?
• Is there an exit clause covering handover of paid work?

Send your brief on WhatsApp and you will get an itemised quote in about two working days, with the pricing model and change process written in. Nothing is billed before your written approval. See all starting prices on our pricing page.