Fixed Price vs Time & Materials: Which Contract Model Actually Works?
A founder came to us last year after a fixed-price contract went badly. The scope had been defined in a 4-page document. The vendor delivered exactly what was in the document. And the product was unusable — the document hadn't specified mobile responsiveness, it hadn't described the error states, and it hadn't included the integration with their existing CRM that everyone had assumed was obvious.
The vendor hadn't done anything wrong. The contract said what it said. The problem was the contract model itself, applied to a situation where it was structurally wrong.
This is not a rare story. And the opposite story exists just as reliably: a Time & Materials engagement where scope crept from a $30,000 MVP to a $180,000 platform because nobody was tracking what was being built or why.
Both models fail in predictable ways. The question is which failure mode is more dangerous for your situation — and how to structure either model to avoid the most common problems.
What each model actually means
Fixed price means you and the vendor agree on a scope and a price before work starts. Changes to scope require a new agreement — a change order, usually at a premium. The vendor takes the risk that the work takes longer than estimated; if it does, that's their problem. You take the risk that the scope doesn't match what you actually needed.
Time & materials (T&M) means you pay for the time and resources the vendor uses. Scope can change. You take the risk of cost overruns; the vendor takes no delivery risk. The total cost depends on how many hours are worked, at what rates, over what period.
In practice, most engagements are a variation of T&M because most software products require ongoing development that evolves as users interact with the product. A truly fixed-price engagement requires a truly fixed scope — which is rare in product development and essentially impossible in AI or data-heavy product work.
When fixed price works
Fixed price works when the scope is genuinely well-defined — not just described, but specified to the level where a competent engineer can implement it without ambiguity, and a QA engineer can write test cases against it before development starts. This level of specification is usually achievable for:
Discrete integrations. "Integrate our product with Stripe, supporting subscriptions and usage-based billing, with webhook handling for the events listed in this spec." If the spec is complete — edge cases, error states, retry logic — this is a legitimate candidate for fixed price.
Well-defined migrations. "Migrate our data from PostgreSQL to a new schema, preserving all relationships, with zero downtime, and deliver a validation report showing 100% row count consistency." The success criteria are objective and testable.
Static site builds from a complete design file. If there's a Figma with every breakpoint specified and a content model that covers every page type, a frontend build can be specified tightly enough for fixed price.
The common thread: you can write the acceptance criteria before the work starts, the criteria are objective and testable, and user feedback won't change what "done" means.
When fixed price blows up
Fixed price blows up whenever the scope is more ambiguous than it appears. This is most of the time in product development. The warning signs:
The spec describes features, not behaviors. "A user management system" is not a spec. "Users can register, log in, reset passwords, and be assigned one of three roles (admin, editor, viewer) with the permissions listed in the attached matrix" is closer. Most fixed-price contracts are written closer to the first description.
The product involves user feedback loops. Any product that will change based on what users actually do — which is most products — is a bad candidate for fixed price. The whole point of building is to learn; fixed price punishes you for incorporating what you learn.
The vendor can hit spec without delivering a good product. This is the subtler failure. A vendor on a fixed-price contract is incentivized to deliver what's in the spec as efficiently as possible, not to build the best product. Technical debt accumulates. Edge cases get minimal handling. Performance gets good enough to pass acceptance, not good enough for real users. QA is often the first thing cut when a vendor is behind schedule on a fixed-price engagement.
The red flags before you sign
If any of these five appear in a vendor proposal, the engagement is likely to be contentious regardless of which model you're using. But they become particularly dangerous under fixed price because there's no correction mechanism once work starts.
When T&M works — and when it doesn't
T&M works well when: the scope is genuinely unknown at the start (new product, AI feature, greenfield data architecture); when the team has the internal structure to manage cost effectively; and when you're willing to be engaged on a monthly basis with the vendor to track and adjust.
T&M fails when there's no management layer — on the vendor side or the client side — tracking what's being built and whether it's still aligned with the product goal. Without that layer, you get sprint plans that expand to fill available capacity, features built at the wrong layer of abstraction, and a cost that accumulates without a corresponding product that feels more finished.
The solution isn't to switch to fixed price. It's to add the management layer. This is what a managed pod model provides: T&M pricing combined with a tech lead who manages scope, a sprint cadence that produces shippable software every two weeks, and a weekly demo that keeps you aligned on what's being built and why. The cost per sprint is variable; the deliverables per sprint are accountable.
What Squash Apps uses — and why
We operate on a T&M model structured around monthly pod retainers. The rate is fixed per month (based on team composition); the scope evolves each sprint based on your priorities.
We've been asked regularly whether we offer fixed-price engagements. The honest answer: yes, for genuinely well-specified discrete projects. We've done them for well-defined integrations, migration work, and specific module builds. In every case, we'll only agree to a fixed price if we believe the acceptance criteria can be written before development starts.
For ongoing product development, we recommend against fixed price — not because it's bad for us, but because it consistently produces worse outcomes for the client. The incentive structure of fixed price pushes vendors toward scope compliance rather than product quality. We'd rather operate in a model where our incentives are aligned with delivering software that actually works.
If you're comparing models and want a concrete proposal for your situation — what team structure makes sense, what a monthly pod costs, and whether a fixed-price engagement makes sense for any part of the work — the staff augmentation and pod page has current configurations. Or book a 15-minute call and we'll give you a direct answer.
Frequently asked questions
Is fixed price or T&M better for an MVP?
For most MVPs, T&M with a managed pod is better. An MVP is, by definition, a learning exercise — you're building to discover what users actually want, which means the scope will change as you learn. Fixed price penalizes you for incorporating that learning. The exception: if you have a very well-specified v1 that you're confident in, fixed price for that specific scope can work. But spec out acceptance criteria first and see if you still feel confident.
How do I protect myself in a T&M engagement?
Three practices: set a monthly spend cap with a defined review process before exceeding it; require fortnightly or monthly demos of working software (not status updates — actual demos); and define sprint goals in advance rather than letting the team define them retrospectively. These don't require the vendor to be adversarial — they're just good operating hygiene.
What's a milestone-based contract?
A milestone-based contract is a hybrid: you agree on phases of work (discovery, MVP, launch), with a payment tied to each milestone being delivered. Each milestone has defined acceptance criteria. It gives you more checkpoints than a pure fixed-price contract while keeping some budget predictability. It's a reasonable middle ground for phased work, though it still requires well-specified acceptance criteria to avoid disputes at milestone delivery.
Can I switch from fixed price to T&M mid-project?
Yes, though it requires renegotiation. We've seen clients switch after a fixed-price engagement delivers technically-compliant code that doesn't actually work for their users — at which point the remaining work is better structured as ongoing product improvement than as a new fixed-price spec. The transition typically involves a codebase review, architecture assessment, and a new engagement structure before the next sprint starts.