Founders rarely fail because their engineers were slow. They fail because the thing they were building was too large, and by the time that became obvious the runway had gone.
We have watched this pattern enough times to recognise it in the first conversation. It always looks the same: a long feature list where every item is described as essential, and no clear answer to what happens if the product launches with only three of them.
The scope conversation nobody wants to have
Our discovery sprint ends with a single deliverable: a feature list where every item has been argued down or cut. The output is uncomfortable because it is honest.
We ask three questions of every proposed feature:
- Does a specific, named user need this to complete the core transaction? If you cannot name the user and the transaction, it is a preference, not a requirement.
- Would the product be worthless without it, or merely less convenient? Less convenient ships. Worthless does not.
- Can it be done manually for the first fifty users? If a human can do it while you learn, automation waits.
Feature three is where most of the savings are. Founders build admin panels, dashboards and automation for volumes they will not reach for two years — then have no budget left for the thing customers actually touch.
Boring technology is a launch advantage
There is a persistent belief that a new venture needs a novel stack to be credible. In practice the opposite is true.
Choose technology that:
- your first engineering hire can pick up without a training period
- has abundant documentation and a large community answering questions at 2am
- you can host cheaply and scale predictably
- does not require a specialist to operate in production
Novelty in the stack is a tax you pay on every future decision. Save novelty for the part of the product that is genuinely differentiated.
Ship the instrumentation with the product
This is the mistake that costs the most and is the cheapest to avoid. If analytics, event tracking and error reporting are not in the launch build, the first month of user behaviour is lost forever — and the first month is when you most need it.
Instrument at minimum:
- every step of the core funnel, with drop-off visible
- errors and failures, with enough context to reproduce them
- basic performance, because a slow product loses users before they form an opinion
- a way to identify which cohort a user belongs to, so you can compare behaviour over time
Weekly demos are a discipline, not a ceremony
We show working software every week without exception. If a week produced nothing demonstrable, that is information the client needs immediately — not something to smooth over before the next update.
Weekly demos do three useful things: they force decisions to be made in days rather than months, they surface misunderstandings while they are cheap to fix, and they give the client confidence that money is becoming product.
Launch is a phase, not an event
The teams that succeed treat launch as the beginning of a measurement period. The teams that struggle treat it as the finish line and are surprised when users do not behave as predicted.
Plan for the four weeks after launch with the same seriousness as the build:
- who is on support, and how fast they respond
- what you will do when the first significant bug appears in production
- which metric decides whether the launch worked
- what you will cut next, because you will need to
The handover is part of the product
When a venture succeeds it hires its own engineers. A good build partner plans for that from the first commit.
That means documentation written as you go rather than reconstructed at the end, a codebase that reads clearly, deployment that is reproducible from a script, and a transition period of paired working so the incoming team ships real changes before the handover completes.
We have handed over several systems this way. It is the correct outcome and it should never be treated as a loss.
A checklist for your next scoping meeting
- Can you name the one user and the one transaction the launch serves?
- Have at least a third of the original feature list been cut, and by whom?
- Is the stack something you could hire for next quarter?
- Is instrumentation in the launch scope?
- Is there a weekly demo commitment in writing?
- Is the handover plan documented, or assumed?
If two or more of those are unanswered, the launch date is fiction.
Applying this to your own organisation?
We would rather diagnose your situation than sell you a product. Book a call and we will tell you honestly whether this is worth doing now, later, or not at all.