People ask how a small studio ships a brand, a website and a working client portal in the time a larger agency takes to finish discovery. The honest answer is a set of deliberate choices about what not to build, plus AI tools used in a specific, supervised way. Here’s the whole approach, including the parts that are unfashionable.

Start with the business, not the stack

Every project starts with the same questions: who is this for, what should they do next, and what currently happens by hand? The stack follows from the answers. For Good Walks, a dog walker needed to approve households before they could book, so the portal is built around that approval step. For Gers Astronomie, guests needed to know whether tonight’s sky was worth it, so the homepage calculates dusk and moon phase and shows a cloud forecast.

If I can’t describe what a feature changes for the business in one sentence, it doesn’t get built.

Static first

Most of what I build is static HTML generated at build time. This site is written in React and TypeScript, but React only runs on my machine. The build renders each page to plain HTML, and the browser receives finished pages, a small stylesheet and a few kilobytes of script for motion and the theme switch. No framework boots in the visitor’s browser.

That one decision does a lot of work:

  • Speed. Pages are served from a CDN close to the visitor.
  • Security. There’s no server or plugin to patch, and nothing to log in to.
  • Search. Search engines and AI tools read complete pages without running JavaScript.
  • Cost. Hosting is effectively free at small-business traffic levels.

Small functions where something has to happen

When a page needs to do something, I add a small function rather than a server. Our enquiry forms are a single Cloudflare Pages Function that checks for spam and sends the enquiry by email through Resend. The Good Walks portal uses functions with a Cloudflare D1 database for households, bookings and walk credits.

Each function does one job and can be read in a few minutes. If a client ever moves to another developer, there’s no mystery server to inherit. I’ve written more about this in free and almost-free backends.

Made for search engines and AI assistants too

Every page on this site also exists as clean Markdown. Ask for a page with an Accept: text/markdown header, or read the index at /llms.txt, and you get the content without the design. Each page carries structured data describing the business, the services and their prices. That’s not a trick: it’s making the site easy to understand for the tools people increasingly use to find a supplier.

How I use AI

I use AI coding tools heavily, and I say so on the website and in every case study. The way I use them matters more than the fact that I do.

What AI does: writes first drafts of code from a precise description, refactors, writes repetitive markup, drafts test checks, and catches things I’ve missed in review. It’s fast and tireless, and it makes a one-person studio able to build things that used to need a team.

What I do: decide what should exist, design the experience, set the constraints, read every change, and decide when something is finished. AI tools are confident even when they’re wrong. My job is to know the difference.

The rule I hold myself to: I only ship work I understand well enough to support. If I can’t explain how a piece of code works, it doesn’t go live, no matter who or what wrote it.

Checks instead of trust

Because AI writes so much of the first draft, the build is wrapped in automated checks. This site’s build won’t pass unless, among other things:

  • every page has exactly one main heading, a unique title and description, a canonical address and a share image;
  • every internal link and image actually exists;
  • the Markdown copy of each page matches the HTML;
  • the enquiry form rejects spam, never redirects to the thank-you page when an email fails, and can’t be used to inject email headers;
  • tracking stays off pages where it shouldn’t load.

These checks are boring, and they are the reason I can move quickly without breaking things clients depend on.

Honest evidence

Case studies on this site say exactly what each screenshot is. Where a product uses staged or synthetic data, the caption says so. Where something is in beta or awaiting client review, the status says so. It would be easy to blur that line, and plenty of portfolios do. I’d rather a potential client trust the work they can see.

What this means for clients

  • You get a fast, secure site that’s cheap to run.
  • You own it. Domain, accounts and code are yours, documented well enough for someone else to pick up.
  • Changes are quick, because the code is small and readable.
  • The parts that matter are tested, especially anything that touches your enquiries, bookings or payments.

What this means for designers

If you’re a designer curious about building: the tools have never been better, and the bar for what you should check has never been higher. Learn enough to read what the AI writes. Keep the architecture boring. Write checks for the things that would embarrass you if they broke. And be honest with clients about how the work is made.