How we work
The useful half of any process page is the part about when it goes wrong.
Every supplier describes the same happy path — discovery, sprints, demos, handover — and the description carries no information because nobody disagrees with it. What separates suppliers is what happens in the week the estimate turns out to be low, the requirement changes after the price was fixed, or the mistake is ours.
The rhythm first, because it is short. Then the four situations that actually decide whether an engagement ends well.
The rhythm
Four loops, each with something you can check
Not a methodology with a name. Four nested cadences, each of which produces an artefact rather than a status update — the distinction being that an artefact can be wrong in a way you can see.
The part that carries information
Four situations, and what we actually do
01 · The estimate was too low
Inside the agreed scope it is our problem, and we absorb it — that is what a fixed price means, and a supplier who reopens it has not sold you one. We do tell you in the week we find out, because an overrun we are quietly absorbing still changes what we would advise about the next phase, and that advice is worth more to you than our dignity.
02 · The requirement changed
If it fits inside the phase, it comes in and something comparable goes out — and you choose which, in the fortnightly review. If it does not fit, it is quoted as a delta and you decide whether it joins this phase or the next. Nothing is accepted silently and raised later as the reason for a delay.
03 · You have gone quiet
Decisions stop arriving, the review is cancelled twice, nobody answers the question blocking the work. We keep going for about two weeks on documented assumptions, then stop and say so in writing rather than continue building on guesses and bill you for the result.
04 · The mistake was ours
We say which decision was wrong, what it cost and what we are doing instead — in the review, before you find it. We do not charge you to fix our own defect. The one thing we will not do is explain it as a misunderstanding of your requirements when it was not.
05 · And the one that is not a failure
Discovery ends in "do not build this". It happens, the fee is the same, and it is the cheapest finding we can produce. A review that cannot reach that conclusion is a sales call with a document at the end.
06 · The disagreement we welcome
You think the architecture is wrong. Say so early and we will argue it in front of the whiteboard — and if we lose, we build it your way and write down that we disagreed, so the record is honest either way.
Your side
What we need from you, stated as hours
Suppliers are vague about this because the honest answer sounds like a demand. It is a small demand and the project fails without it:
- Someone reachable on most days. Not full time — available. Questions that wait three days to be answered become assumptions, and assumptions become rework.
- Two hours a fortnight for the review. With the person who can say yes. A review attended by people who then have to ask somebody else is a presentation, not a review.
- One named decision-maker. The single biggest difference between a project that runs at engineering speed and one that runs at meeting-calendar speed. No amount of technical competence compensates for its absence.
- Someone who will still be there afterwards. Named at the start, paired with from the first week, not found in the final fortnight.
Stated once, linked from everywhere
The commitments, and where each one is written out
Each of these is defined in exactly one place on this site. Repeating a commitment in four pages is how it quietly drifts into four different commitments.
Who is on the engagement
The roles, the sizes we have actually run — two, six, ten, eleven — and when each role is not needed — the team model, with the real numbers
What a finished handover means
Five things a stranger must be able to do, none of them needing a call to us — the handover test
The contract, when we place engineers
Replacement, exclusivity, the clause that lets you hire them, and who owns the code — four clauses, printed
Why none of this is staff leasing
The statutory division between a contract for services and the supply of labour, and what crossing it costs both sides — who directs what
Questions
The ones worth asking any supplier
What happens when your estimate turns out to be wrong?
We tell you in the week we find out, not in the week the phase was due. A phase is fixed price, so an underestimate inside the agreed scope is our problem and we absorb it — that is what fixing a price means and a supplier who renegotiates it has not sold you a fixed price. What we do ask for is the right to say so out loud, because an overrun we are absorbing quietly still changes what we would advise about the next phase, and you should have that information while it is useful.
Our requirements will change. How does that work against a fixed price?
A change that fits inside the phase comes in and something equivalent goes out, decided by you in the fortnightly review rather than by us. A change that does not fit is quoted as a delta and you choose: add it to this phase at that price, or put it in the next one. What we do not do is accept it silently and bring it up as the reason for a delay later. Scope arguments at the end are almost always scope decisions nobody recorded at the time.
What do you need from us, in hours?
Less than most suppliers ask for and more than none. Roughly: one person available for questions on most days, two hours a fortnight for the review, and a named person who can make a decision without convening anybody. The last one matters most. A project where every decision needs a meeting runs at the speed of the meeting calendar, and no amount of engineering compensates for it.
Who do we actually talk to?
The people doing the work, not an account manager relaying for them. On a small engagement that is one or two engineers; on a larger one there is a project manager whose job is the plan and the schedule rather than translating between you and the team. If you ever find yourself explaining something technical to somebody who cannot answer technical questions, that is a failure of ours and worth saying so.
What if we want to stop?
Phases are the unit precisely so that stopping is cheap and uncomplicated. At the end of any phase you have working software in production, the repository, a build that runs on a clean machine, migrations, a runbook and decision records — and the handover is rehearsed at every phase boundary rather than attempted once at the end. Stopping after phase two should cost you a notice period and nothing else.
Do you work in our process or your own?
Yours, where you have one. Your branch strategy, your review standard, your definition of done, your ticketing. We have opinions and will offer them once, and after that it is your system and your rules. The single thing we insist on is that decisions get written down where the code is, because a decision that lives only in a chat thread does not survive the person who had it.
Next step
Ask us about a project that went badly
It is a better question than any reference call, and we will answer it. A supplier with no such story has either not worked long enough or is not telling you one.