When you need a website
(and when you don't).

// 01

Do you need a website at all?

The honest answer for a small operator: not always. If your whole business runs through Instagram DMs, WhatsApp orders and word-of-mouth, a website often delivers no marginal value beyond a Google Business listing. Spending £2k on something nobody clicks is a tax on growth.

You probably do need a website if any of these are true:

• You want to be found in Google when someone searches for what you do.
• You sell to other businesses (B2B) — you'll be Googled before any meeting.
• You take bookings, quotes, or payments and the current process leaks customers.
• You want one credible link to put on a van, business card, ad or invoice.
• Customers regularly ask the same questions and you keep retyping the answers.

You probably don't need one (yet) if:

• You're fully booked from referrals for the next 6 months.
• Your buying audience is exclusively on one channel that already converts.
• You've never tried a Google Business profile — start there, it's free.

// 02

Website vs landing page

These are not the same thing. The difference matters because it changes what you should pay for.

A landing page

One page, one objective. Usually paired with paid ads or a launch campaign. Goal: a single conversion (sign-up, demo, purchase) measured against ad spend. Lifespan: weeks to months. Cost: typically £400 — £1,500.

A website

Multiple pages, multiple intents (services, about, case studies, blog, contact). It's your owned address on the internet — discoverable in Google, quotable, linkable. Lifespan: years. Cost: £1k — £10k+ depending on scope.

How to choose

• Running a paid campaign? Build a landing page for that campaign. Don't send paid traffic to your homepage.
• Want to show up in organic search? Build a website with structured pages per service.
• Both? Most growing businesses end up with a website + 1–3 dedicated landing pages it can spawn for campaigns.

// 03

Website vs web app

A website mostly shows you things. A web app mostly lets you do things. The line moves around, but the practical signal is: does the user log in?

Website territory

• Marketing pages, blog, portfolio, contact, FAQs, pricing.
• Maybe a contact form, a newsletter signup, an embedded booking widget.
• No persistent user state. No accounts.

Web-app territory

• User accounts, dashboards, real-time data, persistent state.
• Roles & permissions (e.g. customers vs admins).
• Background jobs (sending emails, processing data, syncing with another system).
• Anything you'd describe as "a tool" rather than "a brochure".

// 04

Security & your data

Most small-business security incidents are not fancy hacks. They are: weak passwords, a leaked API key in a public Git commit, an unpatched WordPress plugin, or a phishing email read at 11 p.m. Everything below is about closing those four holes — not the movie ones.

The minimums for any site

• HTTPS everywhere (Let's Encrypt is free; there is no excuse for HTTP in 2026).
• Strong, unique admin passwords + 2FA on the host, the CMS, the email and the domain registrar.
• Up-to-date dependencies. WordPress / Drupal sites must update themes & plugins automatically — most breaches are out-of-date plugins.
• Backups you've actually tested restoring. A backup you've never restored isn't a backup, it's a guess.
• A privacy policy and cookies notice if you're in the UK/EU. The ICO expects them.

If your site collects data (forms, accounts, orders)

• Never store passwords as plain text — bcrypt or argon2 only.
• Encrypt sensitive fields at rest where the database supports it.
• Limit who has admin access. If a contractor leaves, rotate their credentials the same day.
• Have a written response plan for what to do if something leaks (see §06 below).

// 05

AI & vibe-coding — when it's OK and when it isn't

"Vibe-coding" is the (semi-affectionate) name for letting an AI assistant write most of your code while you steer with prompts. It's great for some things. It's genuinely dangerous for others.

Where vibe-coding works well

• One-off scripts, prototypes, internal tools you'll throw away in a month.
• UI tweaks, copy edits, design experiments on a marketing page.
• Spike work — exploring an idea before deciding to build it properly.
• Personal projects where only you bear the consequences.

Where it goes badly wrong

• Anything handling other people's money or data. AI assistants will happily produce code that opens a SQL injection, leaks emails, or skips an authentication check, and the code will look completely fine to a non-engineer.
• Production deployments without review. AI is great at writing code; it is not yet great at noticing what it forgot to write.
• Authentication, payments, encryption. Don't roll your own from a chat — use a battle-tested library (Auth.js, Clerk, Stripe).
• Anywhere a small mistake costs months to undo — schema migrations on a real database, deleting data, deploying credentials.

The rule we use

AI writes the code. A human reads it before it ships.If nobody on your team can read it critically, that's the moment to bring in someone who can — at least for the parts that touch users, money or data.

// 06

What if your data — or your secrets — leak?

The two most common ways small businesses get hurt:

You pushed an .env file to a public Git repo

The .env file usually contains API keys for Stripe, OpenAI/Anthropic, your database, your email provider. Anyone reading your repo can copy them. They will. There are bots that scan GitHub continuously for exactly this — keys are often abused within minutes of being pushed.

If it happens to you, in this order:

• Rotate every key in that file at the provider (revoke the old one). Never "just delete the file" — the commit is still in history.
• Check usage logs at each provider for the past 24 hours. Look for spikes.
• Disable any auto-billing tied to those keys (especially LLM APIs — bills can hit £1,000+ in hours).
• Add the file to .gitignore, then re-write history if the repo is private (BFG Repo-Cleaner). If it's public, accept it's out and focus on rotation.
• Tell anyone whose key you used if you're working with a client. They'll appreciate it more than they'll be angry.

Your customer database leaked (UK GDPR territory)

If personal data is exposed (emails, names, payment info), under UK GDPR you generally must:

• Notify the ICO within 72 hours of becoming aware, if there's a real risk to people.
• Notify affected individuals if the risk is high (financial loss, identity theft).
• Document what happened, what you did, and what you changed afterwards.

Failing to report when you should can be a much bigger problem than the breach itself. The ICO's line is: "tell us early, even if you don't yet have the full picture."

// 07

A quick checklist before you ship anything

• HTTPS is on, certificate auto-renews.
• .env and any credentials are in .gitignore, never committed.
• 2FA is on the host, CMS, email, registrar, payment processor.
• Backups run automatically AND you've tested a restore.
• Dependencies update automatically (Renovate, Dependabot, or your CMS's built-in).
• You have a privacy notice and cookies page.
• Forms have rate-limiting and basic spam protection (honeypot + sensible validation).
• Error monitoring is on (Sentry, Vercel/Netlify analytics, or just a daily uptime ping).
• One person who isn't you knows how to log in if you're unavailable.

If half of those are missing, that's usually where to start — not on redesigning the homepage.