A defined build, a named team and a date everyone signed up to. We run discovery, delivery and handover, and you finish owning the system rather than the relationship.
Project-based is the right shape when you know what needs to exist and want one team accountable for producing it. We agree the scope, the sequence and the acceptance criteria up front, then run the build against them — with the awkward parts scheduled first, while there is still room to react.
Five things that come as standard, because leaving any of them out is what turns a fixed price into an argument.
Project-based rewards clarity. If the requirement is still moving weekly, a dedicated team is usually the cheaper answer — we will say so.
A launch, a funding milestone, a trade show. One team, one scope, and a plan that treats the date as a constraint rather than a hope.
A system whose behaviour is known because it is running. The specification exists — it is just currently written in legacy code.
Work that has to be evidenced as much as built: documented decisions, traceable changes, and an artefact trail that survives review.
One workstream inside a transformation you are already running, delivered alongside your teams and vendors without taking over the whole thing.
Silver Jeans Co. sells across women's, women's plus and men's ranges, with customer accounts, order tracking, a loyalty programme and a separate resale channel. Each surface knew something about the customer; none of them agreed on who that customer was.
The scope was defined before the build: agree what a customer, an order and a membership mean in the org, model loyalty and resale against the same record, and keep the work declarative — configuration first, code only where it earned its place.
Read case study
Northgate Retail forecast demand across 240 store locations through a chain of spreadsheets that only two people fully understood, and neither of them could take a holiday at the same time.
A bounded piece of work with a clear finish line: rebuild store-level forecasting on a data platform with real tests, then hand it over documented. The old process stayed running in parallel until the new one had proved itself.
Read case study
Argent Energy ran a metering platform with availability commitments written into contracts and no instrumentation capable of demonstrating whether they were being met.
Scoped as a defined reliability programme: service level objectives agreed with the business, the telemetry to measure them, and an incident process rehearsed rather than documented and forgotten.
Read case study
Three failure modes account for most unhappy fixed-price engagements. Select one to see how we handle it.
Occasional notes from the people doing the work.
No newsletter cadence to promise yet — we write when there is something worth saying, and you get it in your inbox when we do.
The engineers who scope your project are the ones who build it. No handover to a junior bench once the contract is signed, and no account layer between you and the people writing the code.
The questions we are asked most about project-based development — how it is priced, who owns what, and when we would tell you to pick a different model.
Through a paid discovery, not a guess against a brief. We spend one to three weeks on the requirement, the systems it touches and the data behind it, and come back with a scope, an architecture and a number. If you decide not to proceed, the discovery output is yours to take elsewhere.
We price the change and show what it does to the schedule, then you decide. Small adjustments usually absorb into the plan; anything material becomes a written change with its own cost and date. What we do not do is quietly absorb changes and let the deadline drift without telling you why.
You do, from the first commit. Work happens in your repository and your cloud accounts wherever possible. There is no runtime licence, no proprietary framework you have to keep paying for, and no technical reason you cannot continue without us.
Architecture notes and the decisions behind them, environment and deployment runbooks, an onboarding guide for a new engineer, and live walkthrough sessions with your team. If nobody on your side can run the system afterwards, we have not finished.
Yes — every project carries a warranty period agreed in the contract, during which defects against the accepted scope are fixed at no cost. New requirements discovered during that period are change requests, and we will be clear about which is which.
They go in the plan as dependencies with dates and owners, the same as our own tasks. Access to systems, sign-off on designs, availability of a subject matter expert — these are the most common cause of slippage, so we track them explicitly rather than discovering them late.
Often. We begin with a short technical assessment so we can be honest about what is salvageable and what is not — and we will tell you if the answer is that finishing it costs more than restarting. That assessment is a small fixed piece of work in its own right.
When the requirement is genuinely still forming. Fixed scope prices certainty, and paying for certainty you do not have is expensive. If the roadmap changes monthly, a dedicated team costs less and moves faster — we would rather say that up front than write a specification we both know will not survive.
Tell us what needs building and by when. An engineer — not a sales rep — replies within one business day.
