THE OFFER
One to two weeks, paid, and it ends in a document you own. We tell you what is load-bearing, what can stay exactly as it is, and the order to deal with the rest in. It is written for the engineers who will execute it, and readable by the person paying for it.
The whole engagement is one to two weeks of our time. It is not one to two weeks of yours: we need about half a day at the start and ninety minutes at the end, and nothing at all in between.
01 CONTEXT & ACCESS
We want three things: what you are building and who it is for, whatever you have already promised customers about launch, and read access to the repository and the infrastructure console. Read-only is enough — we do not need write access at any point in the assessment.
02 INDEPENDENT ASSESSMENT
No standups, no daily check-ins, no progress theatre. We read the code, run it, look at the data model, watch what the infrastructure actually does, and write down what we find. If something is genuinely ambiguous we ask once, in writing, and carry on. You get findings rather than questions.
03 DECISION WORKSHOP
We walk the findings with you and anyone who will have to execute them. We disagree about the order in the open, in front of the people who will live with it. Nobody leaves with a document they have not already pushed back on, and the decisions we reach go into the final version.
The assessment is deliberately opinionated about priority, not volume. A finding only earns its place if it changes a decision: what can stay, what needs to move, or what should happen first.
The list does not change per client, because a list that changes per client is a list somebody is choosing in order to find what they already wanted to find. What changes is which of the ten turn out to be load-bearing for your product — usually two or three — and the report says which, and why.
The indigo line under each dimension is the question that dimension exists to answer. If a finding does not help you answer one of those ten questions, it does not go in the report.
You own the output outright. There is no licence, no right of first refusal and no clause that makes it awkward to take somewhere else — that is the whole point of writing it down rather than telling you in a call.
Every finding with three things next to it: the cost of doing nothing, the rough cost of fixing it, and the point in the sequence where fixing it is cheapest. Findings where the first number is smaller than the second are marked “leave this alone”, and we mean it.
What stays exactly as it is — in most assessments that is the majority of the codebase — and what has to move. Anything on the change side carries the reason, so you can disagree with us on the evidence rather than on authority.
Drawn twice: as it should be at launch, and as it would need to be at roughly ten times your current traffic, with the difference between the two marked. You are not asked to build the second one now. You are asked to not make it impossible.
Tranches in an order, each one shippable on its own, written for an engineer who has never spoken to us. If it only makes sense with us in the room, it is not finished.
What we disagreed about, what you decided, and why. Six months later this is usually the most useful page in the document.
Delivered as a document, not a slide deck. Written in Markdown so your engineers can put it in the repository, next to the thing it describes, and exported to PDF for anyone who would rather have one.
From whoever knows why the product is shaped the way it is. Usually a founder, sometimes the person who built it. Not a committee.
To the repository and to the infrastructure console. Read-only is enough and we never ask for write access during an assessment.
Whatever you have already told customers, investors or your own team about launch — in writing or otherwise. It changes the sequence more than anything in the code does.
For the workshop, with everyone who will have to execute the outcome. This is the one meeting we will not let you send a deputy to.
Repository access is requested after we have both agreed there is a fit, never on the contact form and never before the call. If the answer to the call is “not yet”, we never asked for it in the first place.
Naming the boundary is cheaper for both of us than discovering it in week two.
Security is one of ten dimensions. We will tell you plainly when you need a specialist, and what to ask them for, which is a more useful thing to be told than a scan report.
We do not issue SOC 2, ISO 27001 or anything equivalent, and we will not pretend the assessment substitutes for one. Where a framework is genuinely coming for you, the roadmap accounts for it.
Nobody is paying us to say we would have named it differently. If a finding does not change what the system does under load, it does not go in.
The default is that working code stays. Where we do recommend replacing something, the recommendation arrives with the cost of doing nothing printed next to it.
If there is nothing running, there is nothing to assess. That is a different conversation and we are happy to have it, but it is not this.
Medical, financial and safety-critical products get qualified carefully before we accept them, because the cost of being the wrong firm for that job is not ours to bear.
No, and in most cases we would argue against it. A rewrite trades a system you understand for a system you do not, and it stops the roadmap for months while producing nothing a customer can see. The default is that working code stays. Where we do recommend replacing something, the recommendation comes with the cost of doing nothing next to it, so you can disagree with us on the evidence.
We sign your NDA, or ours if you would rather not draft one. Access is read-only and scoped to what the assessment needs, and we ask for it after we have agreed there is a fit rather than before. We only name clients or publish work with their explicit permission. Otherwise, the engagement stays private.
No. We are positive about AI and no-code as validation tools and would rather assess a product that has already proved somebody wants it. AI-generated code fails in recognisable ways — error handling that swallows the error, authorisation enforced in the interface and not on the server, schema decisions taken by whichever prompt came first — and recognisable failures are findable and mostly cheap to fix.
That is who it is written for. The roadmap assumes its reader has never spoken to us: tranches, sequence, and the reasoning behind each decision, in enough detail for an engineer to execute without a handover call. If your team can only use it with us in the room, we have written it badly.
No. There is no obligation and no right of first refusal. You own the output and can implement it with your own team, with us, or with another provider entirely. The document is deliberately vendor-neutral, which is the point of writing it down instead of telling you.
No, and it is a common starting point. Being live changes the sequence rather than the assessment: we work out what can change without downtime, what needs a migration path, and what has to wait for a window. Nothing in the method requires you to stop shipping while we do it.
No, and in most cases we would argue against it. A rewrite trades a system you understand for a system you do not, and it stops the roadmap for months while producing nothing a customer can see. The default is that working code stays. Where we do recommend replacing something, the recommendation comes with the cost of doing nothing next to it, so you can disagree with us on the evidence.
We sign your NDA, or ours if you would rather not draft one. Access is read-only and scoped to what the assessment needs, and we ask for it after we have agreed there is a fit rather than before. We only name clients or publish work with their explicit permission. Otherwise, the engagement stays private.
No. We are positive about AI and no-code as validation tools and would rather assess a product that has already proved somebody wants it. AI-generated code fails in recognisable ways — error handling that swallows the error, authorisation enforced in the interface and not on the server, schema decisions taken by whichever prompt came first — and recognisable failures are findable and mostly cheap to fix.
That is who it is written for. The roadmap assumes its reader has never spoken to us: tranches, sequence, and the reasoning behind each decision, in enough detail for an engineer to execute without a handover call. If your team can only use it with us in the room, we have written it badly.
No. There is no obligation and no right of first refusal. You own the output and can implement it with your own team, with us, or with another provider entirely. The document is deliberately vendor-neutral, which is the point of writing it down instead of telling you.
No, and it is a common starting point. Being live changes the sequence rather than the assessment: we work out what can change without downtime, what needs a migration path, and what has to wait for a window. Nothing in the method requires you to stop shipping while we do it.
Seven questions, about three minutes, then a scheduling link. On the call we work out together whether an assessment is the right thing for you right now. Sometimes it is not, and we will say so — that is also a useful answer, and it costs you nothing.