Nearly every first call with a prospective client eventually turns into a pricing conversation, and nearly every pricing conversation treats fixed-scope and dedicated-squad as if one were simply cheaper or more expensive than the other. They're not substitutes. They solve different problems, and choosing between them based on budget alone is how engagements go sideways in month two.
I've sat on both sides of this conversation now — as the agency pitching the work, and in earlier roles as the client approving the budget — and the engagements that went badly almost never failed because the price was wrong. They failed because the model didn't match the actual shape of the uncertainty in the project, and nobody said so out loud at the start.
Fixed scope works when the destination is known
A fixed-price, milestone-based engagement only works when the deliverable can be specified tightly enough that both sides agree, in writing, on what "done" looks like before work starts. That specificity is the entire value of the model — it gives a client budget certainty and gives us a clear bar for acceptance.
- The product has a defined scope: an MVP, a specific integration, a bounded feature set.
- Requirements are unlikely to change meaningfully once discovery is signed off.
- There's a hard deadline — a fundraising milestone, a compliance date, a launch event — that scope has to bend around, not the other way.
Dedicated squads work when the roadmap is alive
A monthly retainer against a dedicated team makes sense when the honest answer to "what does done look like" is "we'll know more after we ship the first version and watch real usage." Paying for a fixed deliverable against a roadmap that's going to change anyway just moves the renegotiation fight from "what are we building" to "what counts as a change order" — the same argument, with worse incentives on both sides.
- The product is live and the backlog is driven by user data, not a pre-written spec.
- The team needs to flex between feature work, performance, and support within the same sprint.
- You want engineering embedded in product decisions, not executing a spec written months earlier.
The hybrid model nobody talks about
Most of our longest engagements start as fixed-scope and convert to dedicated squad — and that sequencing is deliberate, not accidental. A bounded discovery-and-MVP phase, priced fixed, de-risks the relationship for both sides: the client sees delivery discipline before committing to a monthly retainer, and we learn the codebase and the team's working style before pricing open-ended capacity. Starting with a retainer on a relationship with zero track record is a bet neither side should be asked to make.
The signal that you've picked the wrong model
It usually shows up by week three, not week one. On a fixed-scope engagement, it's a client asking for something reasonable that's genuinely outside the signed spec, and the conversation turning tense because neither side planned for that to be a negotiation. On a dedicated-squad engagement, it's a client asking 'what will we have by the end of the quarter' and realizing nobody can answer with confidence, because capacity was sold without ever translating into a roadmap commitment.
- If change requests are arriving weekly on a fixed-scope project, the scope was never actually fixed — stop re-signing addenda and renegotiate the model.
- If a dedicated squad has gone two sprints without a shippable outcome a client can see, the retainer has drifted into open-ended R&D without anyone agreeing to that.
- Revisit the model choice explicitly at the three-month mark on any engagement — it's cheap to course-correct early and expensive to discover the mismatch at renewal.
In closing
The question worth asking isn't "which model costs less" — over a long enough engagement they converge. It's "how much is actually knowable about the destination right now," and the honest answer to that question picks the model for you.
