The process

Six stages, and you can stop after any of them.

Every stage produces something you keep — a written scope, a plan, working software, documentation. If you decide at any point to stop, or to take what exists to somebody else, that is a normal outcome rather than an argument.

Start at stage one → What if something changes?

select a stage · advancing automatically

stage 01 / 06 typical duration — —

—

—

You receive
    We need from you

      First callNo charge
      ScopeWritten, fixed
      ProgressVisible weekly
      At the endYou own it all

      Stage one, in detail

      What the first twenty minutes are actually for

      Not a sales call, and deliberately not a demo. The purpose is to establish whether there is a real problem here, whether we are the right people for it, and what it would take.

      The most useful thing you can bring is the problem rather than the solution. "Enquiries dropped by half in March" tells us far more than "we need a new website" — the first is a symptom we can investigate, the second is a conclusion that may or may not follow from it.

      A meaningful share of these calls end without a proposal. Sometimes the answer is a setting in a system you already own, sometimes it is a subscription product, and sometimes it is that the timing is wrong. None of those are failures of the call — they are the call working.

      Bring

      The symptom, not the diagnosis

      What changed, when you noticed, what you have already tried. Numbers if you have them, impressions if you do not.

      Bring

      Who decides

      Whether you can commit, or whether there is a partner, board or head office involved. This changes the shape of everything that follows.

      Bring

      The real constraint

      A hard date, a budget ceiling, a system nobody is allowed to touch. Constraints stated early are useful; constraints discovered late are expensive.

      Do not bring

      A feature list

      Useful later, unhelpful now. Starting from features skips the question of whether they solve anything.

      Do not bring

      A competitor's site

      Fine as a reference for taste. A poor basis for scope, because you cannot see what is failing behind it.

      Do not bring

      An apology for the current site

      Everyone does this. We have seen considerably worse and are not here to judge decisions made under different circumstances.

      Interactive

      What happens if something goes wrong

      Every process looks tidy until reality reaches it. These are the seven situations that actually come up, and what each one means in practice.

      Most agencies answer these in a contract nobody reads. They are worth agreeing out loud, before there is any tension attached to them — which is why they are on a public page rather than in a clause.

      —

      —

      —

      Division of labour

      Who does what

      Projects rarely stall on technical difficulty. They stall waiting for a decision, a photograph, or access to something.

      Our side

      What we are accountable for

      • Asking the awkward questions early. Including the ones that might reduce the size of the project.
      • A written scope with its assumptions. So that when something changes, it is visible which assumption moved.
      • Progress you can see. A working environment you can open, not a status update describing one.
      • Flagging problems the week they appear. Not in the final week, when there is no time left to respond.
      • Testing before you see it. You should be reviewing decisions, not finding broken links.
      • Handover that actually works. Documentation written for whoever comes next, not for us.
      Your side

      What we need from you

      • One person who can decide. Consulting others is fine. Design by committee, at speed, is not.
      • Content and access, early. Text, images, logins. This is the single most common cause of delay by a wide margin.
      • Feedback in rounds, not trickles. Collected and sent together, so changes can be made once rather than five times.
      • Honesty about the budget. A range lets us propose something that fits. No range means proposing blind.
      • Telling us when priorities shift. Internally, in your business. We would rather replan than discover it at review.
      • Saying when you disagree. Politely accepting something you dislike produces a result nobody wanted.

      Honesty

      Where projects like this go wrong

      Not technical failures. In our experience these six account for nearly every project that disappoints, and most are visible early enough to prevent.

      01

      Content never arrives

      The build finishes and waits months for text and photographs. Deciding who writes what — and by when — belongs in the scope, not in an email later.

      02

      The decision-maker changes

      Halfway through, someone new joins with different opinions. Legitimate, and it is a replan rather than a free revision.

      03

      Scope grows one item at a time

      No single request is unreasonable. Twenty of them are a different project. We track them visibly rather than absorbing them until the timeline quietly breaks.

      04

      Approval by silence

      Nobody objects, so it ships. Then it turns out three people had reservations they did not voice. We ask directly rather than treating quiet as consent.

      05

      Launch is treated as the end

      It is the middle. Sites need content, monitoring and adjustment afterwards, and projects that budget nothing for it decay within a year.

      06

      Success was never defined

      Without agreeing at the start what "working" means, the result is judged on taste. Which means it can never be finished.

      Shape of a project

      Where the weeks actually go

      Three project sizes, drawn to scale. Blue is our work, green is yours, and the hatched blocks are the thing that decides most timelines: waiting.

      Notice how little of the elapsed time is building. On a typical project the largest single block is content and feedback — which is entirely within your control, and is why we ask for it in week one rather than week five.

      Our work Yours Waiting —