Fixed price and time and materials answer the same uncomfortable question differently: who pays when the work costs more than expected? A fixed price sets the price for a defined scope, so the agency absorbs the estimating error on that scope. Time and materials bills the actual effort, so you absorb it — and keep the freedom to change direction. This guide is built around reading a proposal the way a buyer should: unresolved dependencies, verifiable deliverables, approval responsibilities, budget checkpoints, and what happens when work stops.
Two proposals can show the same total and describe completely different deals. The number at the bottom tells you what the agency hopes to charge; the pages above it tell you what the agency believes is known, what it is assuming, and what it has quietly left for you to resolve. Learning to read those pages is the actual skill this guide teaches.
One note on how this guide is built: it mixes two kinds of material. Some passages describe how these contracts work — the mechanics. Others describe what is worth negotiating — advice. I keep them separate. Mechanics describe the agreement; advice is my recommendation, not a proven outcome.
Mechanics: the agency agrees to deliver a defined scope for a set price. If the defined work costs more than estimated, the difference comes out of their margin, not your budget. That is the whole of the model's promise — and its limit. It does not promise the scope was the right scope. It does not automatically fix the timeline: whether dates are committed, what counts as a delay, and what happens then all depend on the contract's wording, not on the words “fixed price”. And it assumes you will hold up your side: a complete specification, timely feedback, and the inputs the team needs — content, access, decisions — delivered when promised.
Our guide to SaaS development planning covers the discipline of writing that specification before anyone estimates against it.
Mechanics: you pay for the effort actually spent, at agreed rates, plus agreed costs. That is a payment method, not a delivery method. It can sit alongside a tightly managed backlog with milestones and deadlines, or alongside a fluid one where priorities shift as you learn. Scope, cadence, deadlines, and change procedures are terms of the agreement — they are not consequences of the model's name. What the model leaves open by default is the total: without agreed checkpoints and limits, there is no built-in moment where the spending has to be justified.
Read a fixed-price proposal as a list of bets the agency is making about your project. Your job is to find the bets they have not named.
Every proposal depends on things outside the agency's control: a third-party API, your existing systems, content you will supply, a decision you have not made yet. A careful proposal names these and says who resolves each one. A vague proposal absorbs them into line items like “payment integration” — one line, no named provider, no stated assumptions. Suppose, hypothetically, a proposal lists “user login” as a single item with no mention of which identity provider is assumed, whether social login is included, or who writes the account-recovery copy. The price is fixed; the meaning of the item is not. Ask what each line item assumes, and get the answers in writing.
For each milestone, ask how you will know it is done without taking anyone's word for it. “Backend complete” is not verifiable. “An admin can create, suspend, and refund a test account in the staging environment” is. Acceptance criteria written in plain language — checkable by someone non-technical — turn milestones into facts both sides can agree on.
A fixed timeline with no approval schedule is fiction. The proposal should say what you must approve and by when: designs, content, test accounts, launch checklists. Stalled approvals stall fixed-price projects just as surely as technical problems do, so your own deadlines belong in the agreement too — not just the agency's.
Even with a fixed total, ask where you will see progress against money spent before the budget is gone: demo cadence, milestone sign-offs, access to a staging environment. A fixed price without visible checkpoints is a leap of faith with paperwork attached.
Read the termination clause before the kickoff call, not after the relationship sours: how either side can exit, what you keep — code, designs, documentation, credentials, accounts — what you owe, and in what form the handover arrives. The best time to agree on the ending is before the beginning.
Here the bets run the other way: the agency is not betting on the scope, so you are. Read the proposal for the controls that keep your side of the bet honest.
Ask what you will see and how often: itemised time reports, what each block of hours produced, and direct access to the work itself. Vague reporting is where open-ended engagements quietly become expensive — not through dishonesty, but because nobody is watching the meter.
Someone has to own the priority order — usually you, or someone you trust, working closely with the team. A proposal that never names that person is describing a team without a steering wheel. If that person is you, be honest about whether you have the hours; if it is someone else, name them in the agreement.
Negotiate the guardrails explicitly: a cap that cannot be crossed without your written approval, a not-to-exceed figure per phase, and — critically — what happens when a limit is reached. Does work pause? Is the scope re-planned? Do you re-authorise? An undefined “we'll let you know” is not a control. DianApps' guide documents the not-to-exceed cap as an established guardrail for this model, which gives you a concrete starting point for the conversation.
Keep one distinction straight: a cap limits what you authorise. It does not guarantee how much gets delivered within it. If delivery of specific features matters to you, that belongs in the acceptance terms, not in the cap.
Open-ended billing still needs closed definitions of done. Agree what completes a feature — working in staging, reviewed against plain-language criteria — so “in progress” cannot stretch indefinitely without anyone having to say so.
Same question as fixed price, same timing: termination rights, what you keep, what you owe, and the handover form — negotiated while everyone is friendly.
Assess scope stability over the proposed delivery period: could your description of the work survive, unchanged, until the planned end date? If integrations are unchosen, user flows unwritten, or key decisions unmade, the honest answer is usually no — and a fixed-price proposal for the full build needs explicit assumptions, a narrower scope, or further investigation before either side commits.
Write the unknowns down explicitly: unresolved technical dependencies (which systems must connect, and whether their interfaces actually support what you need), missing acceptance criteria (what “working” means for each part), and decisions that could materially change the estimate (user roles, platforms, billing model). Naming them is the work. The list itself becomes the brief for whatever comes next.
Then choose the smallest engagement that resolves the unknowns. The options: a paid discovery phase that ends with a written scope and plan; a bounded technical investigation into the one or two riskiest unknowns; a smaller defined release that ships the core workflow first; or a capped exploratory engagement with explicit spending limits and a decision point at the end. A discovery phase is a practical way to reduce uncertainty, and it is often the right first step — but it is not mandatory for every project, and it does not eliminate uncertainty. What matters is that the next step has a defined end and a defined output, so you are buying information, not just time.
Write down the scope, the dependencies, the acceptance criteria, and the open decisions. If the description would survive until the planned end date, a fixed price is viable. If not, list the unknowns and choose the smallest engagement that resolves them.
Fixed price needs concentrated upfront work and disciplined milestone reviews. Time and materials needs ongoing attention to priorities and spending. Choose the involvement you will actually maintain.
Use the reading guides above: dependencies, verifiable deliverables, approvals, checkpoints, limits, and the exit. The terms around the number matter more than the number itself.
Termination, handover, and ownership — settled before kickoff, while everyone is aligned.
It can be, because the agency carries the estimating risk for the defined scope and prices accordingly. What the difference buys is budget certainty for that scope — not a better product, and not the right scope. Compare a fixed quote against a capped hourly estimate, not against an uncapped best case.
Yes. The parties can agree to a transition: a defined discovery or first release, then a different arrangement once real feedback reshapes priorities. Agree where that transition happens in the initial contract rather than improvising it later.
Name the unknowns first — dependencies, criteria, decisions. Then buy information in the smallest sensible unit: a discovery, a technical investigation, a small defined release, or a capped exploratory engagement. After that, the build itself can be quoted with confidence under either model.
Scoping a build now? Our project cost calculator gives indicative cost and timeline ranges from your scope and complexity — a useful starting point before any pricing conversation. Or discuss your project with us directly, and we will help you think through which model fits what you are building.
SaaS Development
How Much Does It Cost to Build a SaaS App in 2026?
SaaS app development cost guide: iCodeLTD projects start from $5,000, with lean MVPs often $5,000–$15,000. Timelines, rates, and cost drivers.
Read moreProduct Delivery
iCodeLTD vs Upwork: Which Is Better for Startup Software Development?
iCodeLTD vs Upwork for startup software development: when a founder-led product team beats a freelance marketplace listing.
Read moreProduct Delivery
iCodeLTD vs Fiverr: What Founders Should Know Before Building an MVP
Compare iCodeLTD vs Fiverr for building a startup MVP. Learn when to choose a founder-led software team and when a freelance marketplace may be enough.
Read moreReady to review scope for AI, SaaS, web, mobile, or automation work?
