Fixed-scope delivery: when productized sprints work — and when they don't

Much software outsourcing is priced by the hour and delivered "when it's done." We sell the opposite: a fixed scope, a fixed price, and a fixed delivery window.

That model has real, describable strengths — and just as real limitations. Since we ask every new client to trust it, we owe you the honest version of both.

#What we sell

Three standardized sprints:

Two things make this not just hourly billing with a nicer label: the scope is locked before work begins, and the price doesn't move when the scope doesn't.

#Why the model works

#Scope lock is a forcing function

An open-ended discovery phase is where "six-week projects" go to die. Locking scope up front forces every requirement onto the table before a single line of code exists.

A large share of development work is deciding — what the page does, where the data comes from, when the button appears. Fixed-scope delivery makes that decision process visible and bounded. You make the calls early, we execute them fast.

#Density beats duration

A one-day window concentrates attention. The sprint starts with everything decided, and there are no calendar gaps where momentum leaks away. Many multi-week engagements contain barely more focused working time than a well-run intensive week.

#Fixed risk on both sides

You know the price before we start. We know the effort before we commit. When both parties understand the boundary, neither side is incentivized to blur it.

#Where the model breaks

Honesty requires naming the failure modes:

Vague requirements. If you "don't know yet" what you need, a fixed scope is fiction. We tell those clients exactly that — the right move is usually a small paid discovery sprint or a deliberately narrower scope.

Undiscoverable constraints. Scope lock assumes the requirements are knowable. Legacy systems, undocumented APIs and third-party integrations that don't exist on paper are where fixed price becomes guesswork. When something looks like it depends on an integration we can't inspect, we flag it before quoting.

Mid-build discovery. The biggest risk. If, during the build, we uncover that the "simple" form actually needs an institutional SSO flow, the fixed scope was wrong — and pretending otherwise would blow the window or the budget.

Our answer to that third one is explicit scope governance:

• scope changes are raised during the sprint, not at delivery
• changes map to add-on sprints or a credibly adjusted price, agreed before the work
• we swallow small surprises; we don't pretend large ones don't exist

A fixed price is a promise about a known scope. The discipline is knowing, in any given project, whether the scope is actually known.

#When to pick each tier

The tier isn't about the client's budget — it's about the size of the decision space.

• DEPLOY1 for a page that exists to communicate and convert. One page, one message, one decision.
• DEPLOY7 when you need several pages working together with forms, booking and measurement — still a content problem, but a structured one.
• DEPLOY30 when you're building a system: auth, data, workflows, roles. At this tier the architecture is the deliverable, not the interface.

And sometimes the honest answer is "none of these." We'll recommend no-touch for projects that genuinely need a long engagement with an on-site team. Fixed scope is the right default, not the only option.

#What we can guarantee

Two commitments we can make with certainty:

1. The price for the locked scope.
2. Full ownership — source code and design assets transfer to you at handover.

What we don't do is sell you a guarantee we can't define. Speed is a property of a bounded problem. The productized sprint works because it binds the problem honestly — and that, more than the price tag, is the product.