The practice
A few times a year, we build somebody else's.
Not many, because the person on the call is the person who writes the code. Here is what that actually buys you.
The gap
The demo works. That was never the hard part.
A prototype has to convince someone in a room. The version that replaces it has to run on a Tuesday afternoon with nobody watching, while four hundred people use it at once and one of them is trying to break it. Below is the distance between those two jobs, drawn to scale.
9 obligations between a prototype and something people can use. A demo shows you none of them.
Three modes
In the order they usually happen
Work out what it should be
-
Most people arrive here second. You have a thing you want to exist, and possibly a prototype that already half exists, and before anyone writes production code we sit with it and work out what it is for, who it is for, what it has to do on the day it works, and what it has to survive on the day it does not. You get the shape of it written down. The decisions, the ones we would defer, and the ones that are cheap now and ruinous in a year. Sometimes the honest answer is that you should not build it, or should build a third of it. That costs the same.
What arrives
- The shape of it written down, in language you could hand to somebody else and have them build from.
- Every decision we made, and which ones we deliberately left open.
- A range for the build, with the end we would bet on marked.
- The argument against building it, where there is one worth making.
Discovery · Architecture · Interface design · Figma · Prototypes
Build it properly
-
The version with the edges on. Empty, loading, error, one item, four hundred items: the states nobody demos and everybody meets. Node and Postgres on the server, React or Vue on the front, TypeScript throughout, tests around anything we would be nervous to change later, and a model behind an interface if a model earns its place. Checked with a keyboard and a screen reader before anyone signs it off, and contrast measured rather than eyeballed. You get the repository, the pipeline and the runbook. Not a licence.
What arrives
- The repository, with its whole history rather than one squashed commit at the end.
- A pipeline that builds, tests and deploys with nobody in the loop.
- The runbook, written for whoever is awake when it breaks rather than for us.
- A keyboard pass and a screen-reader pass, with the contrast measured.
TypeScript · Node.js · React · Vue · PostgreSQL · Next.js · Stripe · Playwright
Make it survive being used
-
The part nobody plans for, because it only arrives if the thing worked. Traffic that is ten times last month, a database that was fine at ten thousand rows, a founder who is now also support. We put the thing on infrastructure that can grow, add the monitoring that tells you which afternoon it will break before it does, and take the pieces that were right for a prototype out of the path of the pieces that have to be right for a business. If what you already have is fine, we say so and stop.
What arrives
- Infrastructure standing in your own account, rented from nobody.
- Monitoring that names the afternoon it will break, while there is still time.
- A load test with an actual number on it, run against the real thing.
- A rollback you have watched work, rather than one we promise exists.
AWS · Docker · CI/CD · Observability · Postgres tuning · Load testing
01
02
03
Architecture
The shape of a thing we build
The handover
What you own when we stop
Software delivered on a licence is software you are renting, and renting it from the people who wrote it is the worst version of that arrangement. Everything in the drawing below moves to you on the last day. Leaving us should cost you the inconvenience of the handover meeting and nothing else.
Before you book
The questions everybody asks first
What does it cost?
There is no price list here, because the honest number depends on what you are building and anybody quoting before they have asked is guessing. You leave the first call with a range and with the end of it we would bet on. That range narrows once the first mode is finished, and it narrows in writing.
We already have developers. Is that a problem?
Usually the reverse. A good deal of the best work here has run alongside a team that was perfectly capable and simply short of the one person who had done this particular thing before. Say so when you book, and working out where the seam belongs becomes the first thing we do.
Who owns what you write?
You do, on the day we stop. Repository, pipeline, runbook, infrastructure and keys, all of it standing in your accounts rather than ours. The drawing above is the whole of it.
How soon could you start?
That answer changes month by month, so it belongs on a call rather than on a page that was built once and cached. Where we cannot start when you need to start, you will hear it inside the first twenty minutes rather than in the third week.
Will you sign an NDA?
Yes, and before you describe anything, so long as you say so when you book. It costs five minutes and it is not a favour.
What happens when it goes wrong?
You hear it from us first, in that week's update, while there is still room to turn the wheel. The alternative is a project that reads green every week until the month it does not, and we have been on the receiving end of that ourselves.
The Call
None of this survives contact with a real problem unchanged.
Which is why the first thing is a conversation rather than a quote. Twenty minutes, and at the end of it you know whether we are the right people. Quite often we are not, and saying so early is cheaper for both of us than finding out in month three.
Free. An NDA before you describe anything if you want one, and nothing chasing you afterwards if you go quiet.