"We want a fixed price, but we want to be able to change things as we go." We hear a version of this on almost every engagement, and it usually gets treated as a contradiction — pick one, cost certainty or flexibility. It isn't a contradiction. It's two reasonable things that get resolved the moment you stop treating "fixed price" and "scope" as the same conversation.
Here's how we actually structure that, end to end.
Discovery is a conversation, not an intake form
The first meetings aren't about extracting a requirements document. As you talk through what you're trying to achieve, we're grouping it — the outcomes you're after, the components that get you there, the constraints we need to design around. Most clients don't arrive with a spec. They arrive with a problem and a rough shape of a solution, and that's the right starting point. Our job in this phase is to listen well enough to turn that shape into something scoped.
We recap before we price anything
Once the conversation is done, we come back with a plain-language recap of what we understood — the goals, the groupings, the components. This isn't a formality. It's the checkpoint where a misunderstanding gets caught for the cost of a follow-up email instead of the cost of rework three weeks into a build. If we got something wrong, we adjust here.
A range first, a number second
At this stage, we can usually give a high-level estimate — a range, not a fixed number. We know clients need this to evaluate us against other options, and pretending we can't provide it helps no one. But a range is honest about where things stand: the scope isn't locked yet, so the number shouldn't pretend to be either. The precise, fixed estimate comes after we've gone deeper on the requirements — reviewed the content, mapped the components, and turned the recap into an actual deliverables list.
What "fixed" actually means
This is the part worth being direct about: a fixed price only means something if it's fixed against a defined scope. "Fixed price on an undefined idea, with unlimited changes allowed during execution" isn't fixed-price work — it's open-ended work with a number attached to it for comfort. That's not a deal we'll make, because it isn't one we could actually honor.
What we do instead: we lock the deliverables list before we quote. That list — not a vague description of the end goal — is what the fixed price is fixed to. Everything about how the work gets built after that point can flex. The scope it flexes around does not, unless we explicitly agree to change it.
We don't disappear until launch day
Once you're on board, we scope the project properly — an initial backlog, the modules involved, a roadmap — and we walk through it with you before any building starts: how we operate, what a typical iteration looks like, what you should expect from us, and what we need from you to keep things moving. Then we get to work, but not by going quiet until the end.
This is meant to be an interactive lifecycle. You're not signing a spec and waiting for a reveal — you're present to clarify scope, comb the backlog with us, and see the work as it's built. We think of it as a joint task force: your knowledge of the business, our technical depth, working the same backlog together.
Every iteration ends in your hands, not ours
At the end of each iteration, we push the working increment to a staging environment for you to use, test, and react to. Depending on the scope, that review happens every iteration or at agreed milestones — sometimes it makes more sense to review a larger batch of work at once rather than approve it piecemeal. Either way, one rule doesn't move: nothing goes to your live environment until you've reviewed and tested it in staging and signed off. That review is where expectations get cemented, misunderstandings surface early, and "why did we build it this way" gets answered while it's still cheap to adjust.
Feedback becomes backlog, and the backlog gets reprioritized
Your feedback from that staging review turns into tasks, and those tasks go back into the backlog for reprioritization. This is where the "agile" half of the engagement actually lives — not as a vague promise of flexibility, but as a concrete mechanism: you decide what matters most to build next, based on what you just saw and used.
Swaps are free. New scope isn't.
Not everything that comes out of that review is a scope change. Trading one planned feature for another of similar size — reprioritizing within what we already agreed to build — costs nothing, because it's not adding work, it's re-ordering it. That's the flexibility a fixed price can actually support.
Genuinely new scope — something beyond the original deliverables list — is handled as a change order. We're upfront that this isn't priced the same as work scoped in from the start: it carries a premium, because picking up new work mid-flight means re-opening decisions and sequencing we'd already locked in, not just adding hours. That's not a penalty for changing your mind. It's what makes the fixed part of "fixed price" mean something for everything that came before it.
You retain real control over the project's direction — what gets built next, what gets reprioritized, what matters most right now. What you're not doing is redefining the boundary of what was quoted without that being reflected in the price. Directional control and scope-boundary control are different things, and keeping that distinction clear is what lets us commit to a number at all.
What "done" looks like
Projects rarely end because the backlog hit zero. New ideas surface as the work progresses, small items scope in naturally, priorities shift — that's expected, not a sign something went wrong. Closeout, in our experience, comes down to a mutual agreement that the solution is ready, and that tends to land at or near one of the milestones we set going in, not at some artificial finish line dictated by an exhausted list.
They rarely end at release, either. Once something is live, clients almost always come back with the next thing — a new module, an integration, a feature the launch surfaced a need for. That's part of why we build the way we do: knowing a client will be back for more is exactly the incentive to build it right the first time, not to cut corners on a one-and-done delivery. It's also why we see ourselves as partners rather than order takers. An order taker builds what's on the ticket and moves on. A partner is still there when you need the next thing, and builds every release knowing that.
That's the lifecycle: a locked scope and a fixed price at the front, a real partnership in how it gets built, and an ending both sides actually agree on — one that, more often than not, isn't really an ending at all. Fixed price and agile were never the contradiction they sound like — they just apply to two different things.