Skip to content
—Process6 — One person, six stages

The reason this is worth writing down is that most of it usually happens at a handover between two companies. Here it does not happen at a handover at all.

  1. 01

    Discover

    Deciding what the thing is, and what it refuses to be.

    • Your problem gets written down in one paragraph, in your words, and agreed.
    • The work is cut: what ships first, what waits, what is not being built at all.
    • The hard constraints surface early — the integration nobody mentioned, the data that does not exist yet, the thing legal will ask about.
    What comes out of it
    A scope, a sequence and a price, in writing.
    What you do
    An hour or two of your time and honest answers about what already exists.
  2. 02

    Design

    The product map first, then the screens it implies.

    • The objects get named — what a record is, what states it moves through, who may touch it.
    • Interface design follows from that rather than preceding it, so the screens cannot promise something the data will not support.
    • The main flows are drawn end to end before anything is built.
    What comes out of it
    A data model and the screens, both agreed before code exists.
    What you do
    Reading it and saying where it is wrong. That is cheapest here.
  3. 03

    Build

    Client, server, database and the admin, as one job.

    • It is built in vertical slices — one whole working feature at a time, front to back, rather than a finished frontend waiting on a backend.
    • You get a running URL early and it stays running, so progress is something you can open rather than something you are told.
    • The admin is built alongside the product, not bolted on at the end when there is no budget left for it.
    What comes out of it
    Working software you can use before it is finished.
    What you do
    Looking at it weekly and reacting. Nothing else.
  4. 04

    Connect

    Payments, mail, messaging, accounting, whatever already exists.

    • The systems you already pay for are wired in rather than replaced.
    • The failure cases are handled explicitly — the timeout, the duplicate, the webhook that arrives twice — because that is where integrations are actually lost.
    • Anything that has to be reconciled later is designed to be reconcilable now.
    What comes out of it
    One system instead of several that disagree.
    What you do
    Access, and the name of whoever owns each existing system.
  5. 05

    Launch

    Live, with the boring parts done.

    • Environments, domains, certificates, backups and the accounts that own them — in your name, not mine.
    • Whoever will operate the admin is walked through it until they are not asking questions.
    • Analytics goes in before launch, not after, so the first week is measurable.
    What comes out of it
    A running product, and every account belonging to you.
    What you do
    Deciding when. The technical readiness is my problem.
  6. 06

    Iterate

    What the first weeks show, acted on.

    • The measurement that went in before launch starts answering questions, and the answers are usually not the ones anyone expected.
    • Changes are made against evidence rather than against opinion, including mine.
    • If the right answer is that nothing more should be built yet, that is said out loud.
    What comes out of it
    A product that gets better for a reason you can point at.
    What you do
    Deciding what is worth the next round.
—StartOpen for new work

Tell me what you are trying to build and what is making it hard. If there is a fit I will say so quickly; if there is not, I will say that too.

Start a project
01
A reply
Usually within two working days, from me.
02
A conversation
Scope, constraints, budget, timing. No pitch deck.
03
A straight answer
Including when I am the wrong person for it.