A Client Website Built Over WhatsApp

Jamie Skelton does close-up magic, mind reading and MC work at weddings, corporate events and private parties. He has a 5.0 score from more than 400 Google reviews and two 2026 wedding awards. He is also busy. On a wedding weekend he has no time for a call about a website.

His old site was on Wix. It worked, but it was slow to change. It also did not show what makes him good: the faces of guests when a trick lands.

This post is about how we built the new one. Jamie did not use a project tool, a design file or a feedback form. He used WhatsApp, the app he already uses all day.

The numbers

The build started on 24 Oct 2026 and the site went live on 25 Oct. Jamie sent about 130 WhatsApp messages in that time. Some were one line. Some were long lists of notes, sent late at night or early in the morning.

How a WhatsApp message became a deployed change

The setup has five parts. None of them is new on its own. The useful part is the loop.

The agents never sent a WhatsApp message. They only read the chat. Every reply to Jamie came from me. That was a choice. A client should hear from a person. An agent that can message a client on its own is a risk I do not need.

I also did not sit at a desk for most of it. I watched the work from my phone and gave the lead session short instructions when something needed a decision.

What Jamie asked for

Most requests were small and specific. That is the kind of feedback that usually waits a week for a "round of changes".

Turnaround depended on the size of the note. A one-line copy change was live in about 5 minutes. A new hero video took about 30 minutes. A long batch of notes took about an hour. A batch of video changes sent late at night was done in about 2 hours, before Jamie woke up.

Why this suits a busy client who is not technical

• There is nothing new to learn. Jamie already lives in WhatsApp. He sent voice notes, photos from his camera roll and lists of notes after a gig.

• Feedback does not wait for a meeting. Each note became a change on the staging site, often before he sent the next one.

• Nothing gets lost. Each request has a commit and a test named after the message. If a later change breaks an old request, the test fails.

• He can see the work. He did not need a status report. He refreshed the site.

For me, it removed the slowest part of client work. Nobody had to copy feedback from chat into tickets, then into code, then back into chat.

What the site does

• One enquiry path. Every "Check my date" button goes to one enquiry page with his Studio Ninja form embedded. A celebratory thank-you page follows.

• Real reactions. Hero video loops of guests who laugh and gasp, on the main pages of the site.

• Reviews that update themselves. A weekly GitHub Action gets new Google reviews and the current score.

• Analytics with consent. Vercel Analytics and PostHog run cookieless by default. A clear opt-in banner follows Irish and EU rules. A typed event list tracks each booking button, so Jamie can see which page sends enquiries.

• The brand. A warm black (#121211) and gold (#c5a059) palette from his old brand, with his own gold S logo.

Not losing Google on the move

A new site must not throw away years of search history. These steps protect it:

• All the page copy is server-rendered, so search engines read the full text.
• Every URL from the old Wix site has a permanent 308 redirect to its new page.
• The site keeps the old Google site verification tag, so Search Console carries on.
• The sitemap, canonical URLs and structured data are all tested.

After the launch

The site is not a black box that only I can change. The README tells Jamie how to edit it himself. He opens the Claude app, picks his repo and says what he wants in plain words. Claude opens a pull request, and he merges it. Prices, venues, reviews and photos all live in one config folder.

For bigger changes, he can still send me a WhatsApp message.