PROTOTYPE → PRODUCTION
AI and no-code got you a validated product. Getting it into production is a different problem. We map the route, name the risks, and hand you a plan you can execute.
Prototype tools are good at the part that used to be slow: getting to something real enough to put in front of someone. That is a genuine advance and we are not sniffy about it. What they do not do is answer the questions that only start to matter once other people depend on the thing.
What they do not do is answer the questions that only start to matter once other people depend on the thing. Who can change it safely. What happens when it fails. Where the money goes when traffic multiplies. Those questions were always there — the prototype just did not have to answer them.
Four things are true of almost every prototype we are asked to look at. None of them show up in a demo, because a demo is one person, on a good connection, doing the thing the product was built to do.
Concurrency, rate limits and race conditions do not appear in a demo of one. They appear on the day the thing works.Concurrency, rate limits and race conditions do not appear in a demo of one. They appear on the day the thing works.
The query that returns in forty milliseconds at a thousand rows is a different query at a million, and it fails at the worst possible moment.The query that returns in forty milliseconds at a thousand rows is a different query at a million.
There is no test that fails loudly and nothing watching, so the first failure arrives as a customer email rather than an alert.There is no test that fails loudly and nothing watching, so the first failure arrives as a customer email.
The cost of a prototype is not paid when it is built. It is paid by whoever makes the second change to it.The cost of a prototype is not paid when it is built. It is paid by whoever makes the second change to it.
None of this means starting again. It means knowing which of them applies to you, how much it will cost you if you do nothing, and what order to deal with the rest in.None of this means starting again. It means knowing which of them applies to you, and in what order.
One to two weeks. We take context and access, assess independently, and finish with a decision workshop. You leave with prioritised risks, what can stay exactly as it is, what has to change, a recommended architecture and a roadmap in an order you can execute.One to two weeks. Context and access, an independent assessment, then a decision workshop. You leave with prioritised risks, what can stay, what has to change, and a roadmap in an order you can execute.
01 CONTEXT & ACCESS
What you are building, who it is for, what you have already promised, and read access to the code and the infrastructure console, and half a day with whoever knows why the product is shaped the way it is. We ask for access at this point and not before.
02 INDEPENDENT ASSESSMENT
No standups and no daily check-ins. We come back with findings rather than questions. If something is genuinely ambiguous we ask once, in writing, and carry on.
03 DECISION WORKSHOP
We walk the findings with you and everyone who will have to execute them, disagree about the order in the open, and leave with a sequence everybody has actually agreed to.
Every assessment covers all ten. The report says which of them are load-bearing for your product, what stays exactly as it is, and the order to deal with the rest in.Every assessment covers all ten. The report says which of them are load-bearing for your product. Most products are only genuinely at risk in two or three.
Whether the shape can carry twelve months of change, or only the next feature.
Whether a second engineer can change it safely without reading all of it first.
Authentication, secrets, and the customer data you are already holding.
Schema, integrity, migrations, and what it takes to correct a single wrong record.
Deployment, cost at ten times the traffic, and who is able to redeploy at 2am.
What breaks first, how you find out, and how long recovery actually takes.
Whether you would know something was wrong before a customer told you.
Where the ceiling is, what raises it, and whether raising it is worth doing yet.
What has to ship to launch, and what is pretending to be essential.
Sequence, rollback, support cover, and the shape of the first two weeks.
Most code review produces a list of things that are not how the reviewer would have done them. That list is close to worthless to a founder, because it does not separate what will hurt you in March from what will never hurt you at all. Three rules keep us on the right side of that line.Most code review produces a list of things that are not how the reviewer would have done them. That list is close to worthless to a founder. Three rules keep us on the right side of the line.
A prototype with real users has been validated in the only way that counts. The default is that it stays. We have to argue our way to replacing something, not the other way round.A prototype with real users has been validated in the only way that counts. The default is that it stays.
Every finding carries a cost of doing nothing and a cost of fixing it. Where the first is smaller than the second, the recommendation is to leave it alone — and we write that down too.Every finding carries a cost of doing nothing and a cost of fixing it. Where the first is smaller, we say leave it.
The document assumes its reader is not us. If it only makes sense with us in the room, it is not finished, and it is not something you can put out to another provider.The document assumes its reader is not us. If it only makes sense with us in the room, it is not finished.
This is the one place on the site where the route genuinely forks. You own the output, and all three of these end in the same place — a system other people can depend on.This is the one place where the route genuinely forks. All three end in the same place — a system other people can depend on.
The roadmap is written for engineers who have never spoken to us. Your team executes it. We are available for review at the two or three points that carry the most risk, or not at all.The roadmap is written for engineers who have never spoken to us. Your team executes it; we review at the points that carry the most risk, or not at all.
A Production Engineering Partnership, usually starting with a defined implementation sprint against the roadmap’s first tranche. It continues only while it is the most useful thing we could be doing, and we will say when it stops being that.A Production Engineering Partnership, usually starting with a defined implementation sprint against the roadmap’s first tranche.
The document is yours and it is deliberately vendor-neutral, which means it also works as a specification you can put out to other providers and compare their answers against. That is a feature, not a leak.The document is vendor-neutral, so it works as a specification you can put out to other providers and compare answers against.
The assessment does not commit you to building with us, and there is no right of first refusal. Writing it down so somebody else could execute it is the point of writing it down.
A short qualification form, 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.
Seven questions, about three minutes. If there is a fit you will get a scheduling link within two working days; if there is not, a short note saying why.