Fixed scope, explained: how we price and why it works

For most projects, we agree on a written scope, quote a fixed price for it, and that’s the price, no surprise invoices. Fixed scope is our default for any work with a definable finish line. People sometimes assume “fixed scope” is rigid or risky, so it’s worth explaining exactly how it works, what it asks of both sides, and why we think it’s the right call for the people paying us. (For when a retainer or hourly arrangement fits better instead, see how we think about pricing.)

How it works

The process is simple by design:

1. We scope it together. A free first call, then real conversation about what you’re trying to build and what “done” looks like. We do the work of turning that into a concrete, written scope, specific deliverables, not vibes.
2. We quote a fixed price for that scope. One number, for everything described in the scope document. You know the full cost before you commit a dollar.
3. We build it. You don’t watch a meter. You watch the work, a prototype in your hands early, progress you can see in shared docs and GitHub.
4. Changes are handled openly. If you want something outside the original scope (you usually will, and that’s fine), we tell you the price and timeline impact before doing it. You decide. No surprises at the invoice.

That’s the whole model. The complexity is front-loaded into the scoping, so the rest is calm.

What it asks of both sides

Fixed scope isn’t free magic, it asks something of each party, and that’s the point.

It asks us to do real thinking up front. To quote a fixed price, we have to genuinely understand the work before we start, which means we can’t paper over uncertainty with an open-ended hourly arrangement and figure it out on your dime. The risk of estimating wrong sits with us, where it belongs. That’s a feature: it forces us to scope honestly.

It asks you to be willing to define what you want clearly enough to scope. This is harder than it sounds, and it’s also good for you, projects that can’t be scoped usually can’t be finished either. If your brief is genuinely “we’ll figure it out as we go,” fixed scope will surface that early, when it’s cheap to address, instead of three months in.

Why it’s better for clients

• You know the cost up front. No anxiety about a meter running, no quarter-end invoice that’s double what you expected. You can budget.
• Our incentives point the right way. On a fixed price we’re paid to finish, well, on time. Efficiency becomes our problem, not your bill, so there’s no reason for the work to drag.
• No padding. Hourly invites padded timelines and busywork. A fixed price for a defined outcome strips the incentive to stretch.
• Clarity for everyone. Both sides know what’s being delivered and what it costs. Disagreements happen at the scope stage, on paper, not mid-project over an invoice.

The honest limits

Fixed scope works best when the work can be defined, a website, an app, a defined integration, a migration. It’s a worse fit for genuinely open-ended R&D where nobody can say what “done” means yet; that kind of work sometimes genuinely belongs on a time basis. We’ll tell you when that’s the case rather than force-fit a fixed quote we’d have to fudge.

And changes are real, scope evolves, you learn things mid-build. The model doesn’t pretend otherwise. It just handles changes transparently, priced and agreed before the work, instead of absorbing them into a meter you can’t see.

This is core to how we work as a studio rather than an agency: clear scope, fixed price, you own the result. If you’d rather know the number before the work than watch a meter during it, tell us what you’re building and we’ll scope it.