Four to eight weeks, written down.

Four weeks when you know what you want and it is a refresh. Eight when we start from a diagnostic and there is a process to work out first. The sequence is the same either way, because skipping a step is what makes a build run late.

Can customers book and pay?

Yes.

21 passed · 0 failed · 1 not run

  • a booking can actually be started, end to end
  • every paid Stripe payment has a booking to match it
  • every paid customer was told when to turn up
  • bounced confirmation emails are being noticed
A real morning check on ShotBot, our own booking system. Check names are exactly as it reports them.

What changes

Five apps, three inboxes, one phone. One line.

01The build

One line, week by week.

  1. Before

    Free call

    Twenty minutes on what breaks when you get busy. If an off-the-shelf tool is the answer, we name it.

  2. Week 0

    Diagnostic

    Your process mapped, then a written plan and a fixed quote. £450, credited against a build within 30 days. Skipped if you already know the package and its scope.

  3. Week 1

    Setup

    Deposit in, scope signed. Every account created in your name: domain, hosting, Stripe, email.

  4. Weeks 2–4

    Build

    A preview link from day one, so you watch it being built. An update every Friday, news or not.

  5. Week 5

    Content and data

    Your words and customer data in. It is the step that slips, so we start chasing it in week two.

  6. Week 6

    Testing

    A real payment on a real card, then refunded. The last slot booked twice at once. Then you test it on your own phone.

  7. Week 7

    Handover

    Training, recorded. A written handover. Every login handed over.

  8. Week 8

    Aftercare

    Two weeks of fixes included. The monthly retainer carries on from there, with a three-month minimum counted from the start of the build.

Everything is in your name from day one. If you ever leave, another developer can pick it up tomorrow.

02After launch

Checked every morning, before you open.

Most of what breaks after launch is not a bug. A key expires, or a payment goes through and the confirmation never sends. Nothing was edited, so nothing warns you.

So the live system is checked every morning, from outside, whether or not anyone has touched it. It comes with the monthly retainer.

  1. ReachableThe site is up, and people reach the current version
  2. ConfiguredIt can still take money: keys, endpoints and access as they should be
  3. The path to paymentA customer can get as far as paying, tested from outside
  4. A live test bookingEvery morning, on a slot no customer can reach
  5. ReconciliationEvery payment matched to its booking, so nobody pays and goes missing
Not run means unknownA card payment with a bank security check. On the live system that would be a real charge, so it is tested on a copy instead. A check that cannot run is reported as unknown, never as a pass.

03Measurement

Every build goes live counting six things.

  • 01Visit
  • 02Booking started
  • 03Time picked
  • 04Checkout
  • 05Paid
  • 06Gave up

Joined up, you see the exact step where people drop out, not just how many arrived.

→Start

Tell us what breaks when you get busy.

The first step is a call, and it costs nothing: twenty minutes on what your business does and what breaks when you get busy. Most projects then start with the £450 Diagnostic: half a day walking your process end to end, with a written recommendation and a fixed quote, credited in full against a build if you go ahead within thirty days. If you already know which package you need and its scope is clear, we quote it directly.


You might not need one.

Three questions. How many enquiries turned into paying customers last month? How many no-shows and cancellations did you have, and what did they cost you? Where do people drop out between first hearing about you and paying?

If you can’t answer all three, that is what the Diagnostic is for. If you can, and you already know which package you need, we quote it directly.

Request a 20-minute call WhatsApp