00 / How we work
Every stage here has a failure attached.
This is the whole method. It fits on one page because there are three of us and a process nobody can remember is not a process. Every stage below says what you get, what we need from you, and what it looks like when it goes wrong, because that last part is the only one you cannot check on somebody else’s website.
01
The first call
45 MINUTES · FREE
You describe the problem. We ask what breaks today, who it breaks for, and what happens if nothing changes for a year. By the end of the call you get one of three answers: yes and here is roughly what it costs, no and here is who to ask instead, or we do not know enough yet and here is the one thing to find out.
What we need from you
Someone on the call who knows how the work is done now. Not a specification. If you had a specification you would not need us.
When it goes wrong
Most no answers happen here, which is the cheapest place for them. We say no when the timeline needs a team we do not have, when the budget and the scope are not in the same room, or when what you actually need is a person on staff rather than an agency.
02
Before there is a number
WE READ IT FIRST
Nobody can price a system they have not opened. We ask for read access to the code and the database and for time with whoever knows why it works the way it does. We look at what the backups actually contain and when one was last restored, which parts of the schema are load-bearing, and which of the integrations has no owner left. Then we tell you what we think it is, including the parts we are not sure about.
What we need from you
Read access, and the person who knows why the nightly job starts at 02:40. If that person has left the company, say so on the first call — it changes everything after it.
When it goes wrong
Sometimes reading it is how we find out that the job is bigger than the budget, or that the thing you asked for is not the thing that is broken. That conversation happens here, before anyone has written a line of code against the wrong assumption.
03
What we build first
THE UGLY VERSION
The first thing we build is the part you are most likely to disagree with: on real data, wired to the real database, with no styling on it. Arguing with a running screen is cheap. Arguing with a specification is expensive and everybody wins the argument. The CSV export and the audit trail go in at the same time, because they are cheap while the data model is still soft and expensive once a report depends on it.
What we need from you
Twenty minutes to look at it and be honest. “It’s fine” is the most expensive sentence in this whole process.
When it goes wrong
If what you open does the wrong thing, that is the cheapest possible version of that discovery. We rewrite the scope with you and say what it costs, rather than spending the next stage quietly making up ground.
04
Handover
CODE, KEYS, RUNBOOK
At the end you get the repository, the credentials, and three written documents: a decision record for every choice that is expensive to reverse, a runbook that says how to deploy it, restore a backup and roll back the last release, and a list of every account, key and domain the system depends on with whose name each one is in. Then you deploy it once yourself, on a call, from your own machine, while we watch and say nothing unless you ask.
What we need from you
One person who will own it afterwards, on that call. Not necessarily a developer. Somebody whose name is on it.
When it goes wrong
If the handover call reveals that you cannot actually run it, that is our problem to fix and we fix it before we invoice the last stage.
05 / After
Then the part nobody sells.
Most of a system’s life happens after this page ends. If you want us to stay, there is a fixed monthly amount for monitoring, backups, deploys and small changes. If you would rather take it in-house, the runbook and the decision records were written for exactly that, and you already have the credentials because you got them at handover rather than at the end. Tell us which of the two it is before the last week rather than after it.
There are three of us. We are not a rotation, we do not sell an on-call tier, and we are not going to put a response time in a contract we would have to break at 03:00 on a Sunday. If your system genuinely needs one, that is a real requirement and the honest answer is that we are the wrong shape for it.