Skip to content

Process

From your requirements to a finished product

Six stages, the same every time. Nothing about it is mysterious, and none of it skips review.

  1. 01

    Requirements

    Half a day

    We agree what the thing is for and who it is aimed at, before anything gets built.

    Most failed projects fail here, quietly, and nobody notices until the end. The specification is short but it is written down, because a vague brief produces a vague first draft, and correcting a vague draft takes longer than writing the thing by hand.

    Your part
    One call, then answers to a short list of questions
    My part
    Turn all of it into a written specification

  2. 02

    First draft

    One to three days

    A version to react to instead of a blank page. This is where the speed comes from.

    What used to be a week of boilerplate and blank pages is now an afternoon. It is not finished, it is a version to argue with, and seeing a wrong version of a page tells you more about the right one than an hour of thinking about it.

    Your part
    Nothing yet
    My part
    Build the layout, the code and the copy

  3. 03

    Review

    Runs alongside the draft

    Every line read, tested and corrected, on real devices. Nothing ships because it looked right on my screen.

    The specific things that come up every time: logic that reads correctly and behaves backwards, dependencies nobody asked for, accessibility quietly skipped, and security handled by hope. None of them announce themselves, which is exactly why this stage is not optional.

    Your part
    Nothing yet
    My part
    Throw out what is wrong, test what is left

  4. 04

    Automation

    Half a day to two days

    The parts that keep working when nobody is watching the site.

    This is the part clients notice most after launch, because it is the difference between a website and something that runs a piece of their business. It should also fail loudly rather than silently, which is a design decision, not an accident.

    Your part
    Access to the tools you already use
    My part
    Wire the forms, the leads and the integrations

  5. 05

    Launch

    Half a day

    Live on infrastructure in your own accounts, documented and handed over.

    Documented well enough that somebody else could pick it up. Not a manual, just the moving parts, where the configuration lives, and what to do when something breaks. If you cannot leave me, I have built the wrong thing.

    Your part
    A review pass, then the go-ahead
    My part
    Deploy, document, transfer everything

  6. 06

    After launch

    Your call

    Changes, additions, or nothing at all. Whichever suits you.

    No retainer is pushed on anyone. Plenty of projects are finished when they are finished. The option exists because some clients would rather have someone who already knows the codebase than brief a stranger every time something changes.

    Your part
    Decide whether you want ongoing work
    My part
    Hourly for defined pieces, or a monthly retainer

One thing worth saying plainly

Tools have got faster. Deciding what to build, noticing when something is quietly wrong, and carrying the consequences have not. That part is still a person, and on your project the person is me.

Start at stage one