Implementation
that leaves a product your team can run and change.
Implementation covers building the working product and handing it over in a state your team can run and change. It matters when the people who will own the code are not the people writing it.
The real question
How much of the product exists only in the head of the person who built it.
Step 04 of 06 · Product & Venture Building
The path
From idea
to launch.
Six steps, each feeding the next. This page is one of them.
- Product discovery
- MVPs
- UX
- Implementation (this page)
- Brand
- Launch support
01Questions
The questions
it answers.
What gets built first inside the agreed scope?
Inside the scope agreed for the MVP, the part most likely to fail is built first, end to end; breadth is added only once it holds.
When does a feature count as done?
A feature is done when it runs on screen and a check fails if it is removed; completion is reported screen by screen.
What happens when a dependency fails?
Which parts may fail is decided before launch, the designed error states are built, and each failure path has been run against the real dependency.
Can your team run it without me?
Your engineers build, deploy and change the product from the repository and the written handover alone.
02Pitfalls
Where it
usually breaks.
A live product with no way to see it fail
The product ships with no error reporting and no logs anyone reads. The first failures arrive as user complaints, with no record of how long they have been happening.
Green checks over a broken screen
Typecheck and unit tests pass, the feature is recorded as shipped, and the screen fails to render or was never built. Each late find makes a green build worth less.
One failing dependency that takes down everything
A third-party API runs out of quota or goes down, and pages that never needed it go down with it. Nobody decided in advance which parts were allowed to fail.
A handover that is a link to a repository
The code arrives with no account of how to deploy it, why it was built this way or what does not work yet. Your team finds out all three in production.
03Approach
How I work
on it.
Build the hardest slice first
I take the agreed scope and designs and build one slice end to end through the riskiest part, with required checks on the main branch before more is added.
Land increments your team can review
I build with AI assistance and review the diffs myself, in small increments your engineers can review and run, each decision recorded with its reason.
Rehearse failure, then hand over
I run the failure paths against real dependencies, then hand over the runbook, decisions and known limits, and one of your engineers ships a change using them.
What you leave with
- A working product: the agreed scope running end to end, with checks on every change and errors your team can see.
- A written handover and runbook your engineers can build, deploy and operate from, with accounts and keys in your name.
- A record of the decisions that shaped the build, each with its reason and what it rules out.
- A list of known limits: what is unbuilt, what is unproven and what will need replacing as use grows.
04Measures
What I
would measure.
Signals to read, not targets to hit: what counts as good enough is your team’s decision.
Time for a new engineer to ship a first change
If it falls, the handover documents carry the knowledge; if it rises, the knowledge is still in someone’s head.
Defects found by hand after the checks passed
A rise means the checks are not exercising what a user sees, so a green build is telling you less than it appears to.
Screens running as a share of screens designed
When reported progress runs ahead of this share, work is being called done before it is, and the gap will surface at handover.
05Evidence
The topic,
in practice.
From my own ventures: mainly the development stage of each timeline, with each venture labelled by its actual stage. They show how I build; none records a handover to another team.
Ventures of my own
YoMaxi
In development, not released: I choose each slice and review the diffs of an AI-assisted build; the core loop is built, with tests on every change.
City Dreams
A trading business with a live site: I built the direct-booking site with AI assistance; it confirms no reservation before payment and has a written deployment runbook.
Deal Wizard
Live as a free public beta: I led development and implementation of the working platform, from listing to exported report, with my co-founder as system architect.
Building or launching
something similar?
Tell me about the product, where it is today and what you need next.