How we work
Project work
Fixed-scope builds and rewrites delivered end to end, from discovery and architecture design through launch.
A defined outcome, a date, and a senior team that owns it from discovery to launch. This is the mode to pick when you know what needs to exist — a rewrite of a system that has outgrown itself, a platform that has to replace a vendor product, a migration with a deadline attached — and the problem is that nobody on your side has the time or the depth to own it.
We run it on the same arc as everything else: discovery, design, development and testing, then deployment and maintenance. Two-week sprints, every pull request reviewed, production deploys weekly rather than a single reveal at the end. You should be able to click on the thing we are building within the first fortnight, and every fortnight after that.
What follows is the part of a fixed-scope engagement that is worth agreeing on before it starts.
What you're actually buying.
Four things, and the first one is the only one anybody argues about afterwards.
What fixed scope actually means
The scope is the thing agreed at the end of design, written down, with the parts that are out of it named as clearly as the parts that are in. A change to it is a conversation about a trade — this instead of that, or this and a later date — not a surprise on an invoice.
Estimating is the part of this work nobody is reliably good at, us included. What we can commit to is that you hear about a slip in the week we find it rather than the week before launch, and that the first thing offered is a re-cut of the scope rather than a request for more time.
Working inside a live business
Most fixed-scope work is not a blank repository. It is a replacement for something that is currently running, currently earning, and currently the thing people call about when it breaks. The plan has to account for both systems being alive at once.
GoCart replaced A2 Hosting's order form — the page every sale in the company went through — while the old one kept taking orders, with the front end owned by a different team on a different release cadence. Two years of work, sixteen months live. Wormhole emptied three legacy billing systems into one platform, one brand per maintenance window, with no billing incident anyone had to apologise for.
The order of operations, when money is involved
On anything that charges a card or provisions infrastructure, the sequence is not a style preference. It decides which failure you get, and one of the two options is much worse than the other.
Create, then check, then charge. An order that exists and has not been charged is a support ticket; a card charged against an order that should not exist is a refund, a chargeback, and a conversation with a processor. More on billing & dashboards.
Built to be handed over
A fixed-scope engagement has a defined end, which means the handoff is not a courtesy at the end of it — it is part of the deliverable, and it is designed for from the first sprint.
Code structured and documented for the developer who inherits it, runbooks for the operational parts, and a deploy pipeline your team can run without us. The full account is on how we work.
Fixed scope is not fixed understanding.
Discovery sometimes contradicts the proposal. A schema turns out to carry a decade of data entry nobody documented, a vendor API turns out not to expose the thing the whole plan depended on, or the feature everyone assumed was load-bearing turns out to have four users. The question is what happens next, and there are only two honest answers: re-cut the scope, or hit the date with the wrong thing.
We re-cut. Wormhole is the clean version of that — three brands, ten years of accumulated billing data, roughly ten thousand customers, and the interesting part of the project was everything we decided not to carry across. Deciding that in month two is a design decision. Deciding it in the final week is an incident.
Two of them, written up in full.
Wormhole
Roughly ten thousand customers moved off three separate WHMCS installations and into Helix — one JSON file per record, one brand per maintenance window, and no billing incident anyone had to apologize for. Two and a half years, a team of ten. The interesting part is everything we decided not to carry.
Read case studyGoCart
A2 Hosting's checkout — the page every sale went through — rebuilt as a Laravel application with no database of its own, talking to a custom WHMCS addon over HTTP. Two years of work, sixteen months live, and a front end owned by a different team on a different cadence, which turns out to be the whole story.
Read case studyWhen this is the wrong choice.
If the outcome is not decidable yet, a fixed scope is the expensive way to buy it. Somebody has to price the uncertainty, and that somebody is us — so the estimate comes back padded, and you pay for the padding whether or not the risk shows up. When the shape of the answer is still genuinely open, an embedded engagement lets the direction change without a change order every time it does.
And if the honest state is that nobody is sure what is wrong yet, the cheapest first move is not a build at all. An audit is a couple of weeks, produces a prioritised report, and sometimes concludes that the work you were about to commission is not the work you need.
If you have a scope in mind, send it and we will tell you what we think it actually is.