From idea to launch.
Five stages. The first two exist to make the third one small, because the fastest way to build software quickly is to build less of it.
Mission
Understand the problem, the customer and the hypothesis. What are we actually trying to find out?
Flight Plan
Define the smallest product capable of testing it — and say plainly what is being left out.
Build
Design and engineer it in tight iterations. You see working software every week, not status reports.
Launch
Deploy it, put it in front of real users, and start collecting evidence instead of opinions.
Next Mission
Use what launch taught you to decide what deserves to be built next. Sometimes that is nothing.
Mission
Before anything gets designed, we work out what we are actually trying to find out. Who has this problem, what do they do about it today, and what would have to be true for this to become a business?
Most of this is conversation. It usually takes days, not weeks, and it is where the largest savings on the whole project are made.
You leave this stage with
- The hypothesis, written in one paragraph
- The customer and the job they are hiring you for
- The single riskiest assumption
- What evidence would count as a yes
- An honest view on whether software is even the answer
Flight Plan
The flight plan defines the smallest product capable of testing the hypothesis — and, just as importantly, says out loud what is being left out and why.
This is where we are opinionated. If something does not earn its place in the first launch, we will say so. You can overrule us; you just cannot do it by accident.
In the first launch
- The one workflow the hypothesis depends on
- Whatever it takes to get a real user to the end of it
- Payments, if the question is whether people will pay
- Enough measurement to know what happened
Deliberately not yet
- Settings, roles and permissions nobody has asked for
- An admin panel a spreadsheet could replace for now
- The second and third customer segment
- Scale you do not have the users to need
Build
Design and engineering in tight iterations. You get working software you can click on every week, in an environment that is a real deployment rather than a demo on someone’s laptop.
We use AI-assisted development throughout, and we are accountable for everything it produces. Speed comes from ruthless prioritisation and experience — not from skipping the parts that make software dependable.
How it runs
- Deployed from day one, not at the end
- Something to click on every week
- Direct access to the people writing the code
- Trade-offs surfaced when they happen, not in a retrospective
- Your repository, your cloud accounts, from the first commit
Launch
The natural destination of an MVP is not a repository, a presentation or a backlog. It is the real world. Launch means deployed, monitored, and in front of people who did not help build it.
Before that happens, a short list gets honoured every time. It is not long, and it is not negotiable.
Next Mission
Real products have users. They get clicked, misunderstood, ignored, loved, broken and occasionally paid for. That is where the useful information is.
A few weeks after launch we look at what actually happened and decide what deserves to be built next. Sometimes the answer is a second mission. Sometimes it is Ground Control. Sometimes it is that the idea needs to change shape, and knowing that in ten weeks instead of ten months is the entire point.
What launch tells you
- Whether anyone completes the workflow
- Where they stop, and what they expected instead
- Whether they come back without being asked
- Whether they will pay, and at what point they hesitate
- Which part of the idea people actually care about
How we make decisions.
Building a startup is chaotic enough. Working with us should feel like the competent crew in mission control.
Evidence over opinion
Launch exists to replace arguments with data. Until then we are all guessing, and we will say so.
Opinionated, but collaborative
If something should not be in the first launch, we will tell you. It is your call — it just will not happen silently.
Fast, not reckless
Speed comes from cutting scope, not from cutting the things that make software dependable.
Ambitious, but pragmatic
We can believe in the enormous version while deliberately building a very small first one.
No lock-in
Your repository, your infrastructure, your accounts, from day one. Leaving should be easy or the relationship is not honest.
Bring us the mission.
Tell us the idea, the problem or the half-built thing. We’ll tell you what the smallest worthwhile first launch looks like.