How We Built This: The Futureformed Website

A quick tour through the stack, the trade-offs, and what AI actually changes when a non-developer builds and maintains their own website.

A bit of background

When we set out to refresh the Futureformed website, the choice of approach was, frankly, a bit of a minefield. There are a lot of options out there. Squarespace and Wix are perfectly serviceable but feel expensive in the era of generative AI, especially when most of what they sell you is a polished editor and some templates. I'd previously used Carrd for sites and it was fine, but I wanted something with a bit more individuality, something that didn't immediately scream "I picked the third theme on the homepage."

So I did what I now do for most non-trivial decisions: I sat down with Claude and brainstormed it out.

The brief I set was simple. The site needed to look distinct rather than templated, be cheap to run, be easy for me to update myself (especially blog posts), be fast and discoverable in the era of AI search, and give me room to actually own the codebase rather than rent it from a SaaS.

After a bit of back-and-forth, we landed on a stack that I'll walk through below. Spoiler: it's all running quite happily, and I update the site myself in plain English most days of the week.

The stack, explained simply

Here's the short version. Claude (the model) does the thinking and the building. Claude Code and Cowork are the two ways I actually drive Claude, one in the terminal and one in a desktop app. Next.js is the web framework the site itself is built on. GitHub is where the code lives. Vercel is where the site is hosted and deployed from. Buttondown powers the newsletter. And Substack gets a copy of every blog post automatically.

Each of those is doing one job well, and they all link together via small bits of plumbing that Claude helped wire up.

How a change actually flows from my head to the live site

Let's say I want to update a paragraph on the services page, or add a new blog post. Here's what happens.

1. I open Cowork (or Claude Code in the terminal) and describe the change in plain English. Something like: "On the services page, change the second paragraph to say X instead of Y, and add a new bullet about workshops."

2. Claude reads the relevant files, makes the edit, and shows me a diff. It's working on a real local copy of the codebase, so I can see exactly what's changed before anything goes anywhere.

3. Once I'm happy, Claude commits the change and pushes it to GitHub. I describe a change, Claude makes it, and a Git commit lands on a branch with a sensible message attached.

4. Vercel picks up the push automatically and deploys a preview. Vercel is wired into the GitHub repo, so every push to a branch triggers a preview deployment with its own URL, which is brilliant for testing changes before they hit production. Pushes to the main branch deploy the live site.

5. I check the preview, and if it's all good, I merge. That's it. From "I want to change this" to "the change is live" can be under a minute for small edits, and maybe ten for a new blog post with images.

The thing I want to emphasise is that there is no admin panel. There is no CMS to log into. The code is the source of truth, and Claude is the editor.

Why I use two different Claude tools

This trips people up, so worth explaining.

Claude Code is the command-line tool. You run it in a terminal, but there's also a Claude Code tab in the Claude desktop app. It's brilliant for fast, focused work when I know roughly what I want and just want Claude to make a change quickly. It feels like pair-programming with someone who reads fast.

Claude Cowork is the desktop app version, with a more visual interface. I use this for anything more involved, whether that's thinking out loud, planning a new section, or building something I can't fully picture yet. It also handles things like skills (reusable prompt templates I've built up for the site), screenshots, and file management more gracefully.

Same underlying Claude, two different surfaces. I switch between them depending on what the job is.

Picking the right Claude model for the job

This is the bit that saves money and tokens, and is worth knowing if you're going to do anything similar.

You don't need the brainiest model to do the simplest things.

For the initial planning and structure of the site, I used Claude Opus. This is the one you want when you're shaping something from scratch. It thinks more carefully, holds more context in its head, and pushes back when your idea is wonky. Worth the tokens at the planning stage.

For day-to-day updates (copy changes, blog posts, small structural tweaks, fixing the odd typo) I switch to Claude Sonnet 4.6. It's substantially cheaper to run and more than good enough for the kinds of changes I make most days. You could even get away with the cheaper but less capable Haiku model for small edits, every token counts.

And honestly, for stuff like fixing a spelling mistake or tightening up a sentence, I just open the file in VS Code (a free code editor from Microsoft), or any other document editor, and edit it myself. You don't need an LLM to fix a typo. You can change the text, save the file, push to GitHub, and Vercel does the rest. Anyone with a basic understanding of how a website is structured can do this.

The general rule I follow: bigger model for planning, smaller model for routine work, no model at all for the things you can do faster yourself.

A note on building your own website (and when not to)

I'm going to caveat all of this, because it matters.

If your website is genuinely mission-critical, sees a lot of traffic, takes payments, handles sensitive data, or is the front door of a business that lives or dies by it, hire a professional. Don't build it yourself with an AI co-pilot, no matter how clever the AI is.

For a solo entrepreneur or a small business where the site is mainly there to explain who you are, what you do, and let people get in touch, building your own with AI is a genuinely satisfying process and gives you total control. But you do need to think about a few things: maintenance (packages get updated, things break, you need to be willing to keep an eye on it), speed and performance (AI can build something that looks great and runs slowly if you don't watch for it), security (environment variables, API keys, dependency vulnerabilities, all things you need at least a passing awareness of), and backups and recovery (know how to roll back when something goes wrong, because at some point it will).

None of this is hard. But it's not free either. Going the DIY route costs you time and attention rather than money. Be honest with yourself about which of those you've actually got more of.

Discoverability in the age of AI

One thing I cared about from the start was being findable, not just on Google but on the AI tools that more and more people use as their first port of call.

Traditional SEO (keywords, meta tags, backlinks) still matters. But there's a newer discipline emerging that goes by various names: GEO (generative engine optimisation), AIEO (AI engine optimisation), or just "how do I get cited by ChatGPT and Claude when someone asks about my space."

Nobody has fully cracked it. The models change, the way they retrieve and cite information changes, and the playbook is still being written. But the early consensus is something I'd have guessed anyway: write authentically, explain things properly, and don't try to game it with thin keyword-stuffed copy. Large language models understand human language. So write for humans and trust that the machines will follow.

We've also added structured data (JSON-LD), made sure the site is properly indexed by Google, and included a `keyTakeaway` field on every blog post specifically designed to be quoted by an AI summariser. Whether all of this works as well as we hope is a question for the next twelve months, but it's a sensible foundation.

The newsletter and Substack pipeline

The newsletter sign-up on the site is powered by Buttondown, which is a small, founder-friendly email tool that I much prefer to the bigger names. It does what it needs to do and gets out of the way.

Separately, every time I publish a new blog post on Futureformed, Claude is set up to also post a version to Substack. This was something we built into the publishing workflow rather than relying on an integration I'd have to maintain. New post goes live, Substack gets a copy, subscribers get notified. One source of truth, two places it shows up.

What the codebase actually looks like

Quick technical note for anyone curious. The site is built with Next.js (a React framework) for the pages and routing, Tailwind CSS for styling (kept fairly minimal and on-brand), TypeScript for type safety (which mostly catches my own silly mistakes), and a simple `posts.ts` file that holds every blog post as a typed object, including metadata like categories, keywords, hero images, and related links.

There's no database. There's no headless CMS. Blog posts are just entries in a TypeScript file, which sounds primitive until you realise that's exactly why it's so fast and so easy to manage. Adding a post is editing one file and pushing it. Deleting a post is removing the entry. Backups are Git history.

What this whole thing actually costs

For full transparency: Vercel hosting is free on the hobby tier, which is more than enough for a site this size, and would scale to a paid plan if traffic grew significantly. GitHub is free for the kind of usage I have. Buttondown is a few quid a month, and scales with subscriber count. The domain is the usual annual fee. Claude is my subscription, which I'd be paying for regardless because I use it for everything else too.

The marginal cost of running this site is therefore close to zero. Compared to a Squarespace or Wix subscription it's already saved me a chunk over the year, and I have a codebase I actually own.

What I'd do differently if I started again

Honestly, not a huge amount. The biggest lesson is that planning is key. Have a broad idea of what your site is going to look and feel like in advance, and don't waste tokens doing that bit. Good old fashioned pen and paper, or dictate some ideas into a note (I use Wisprflow) and give that to Claude as context. Front-loading that bit pays off.

The point

A few years ago, building and running your own website was a meaningful undertaking unless you were happy with a template. Now, if you're prepared to learn a bit and lean on AI for the heavy lifting, it's genuinely accessible.

That doesn't mean every business should DIY their site. It does mean the bar for "do we hire someone or can we do this ourselves?" has moved, and probably more than people realise.

No website is ever finished. This one will keep evolving. But I feel good about the foundations and the workflow, and writing this post was itself a 10 minute job: open Cowork, describe what I want, watch it appear.

If any of this is useful or you fancy a chat about your own setup, drop me a DM or come and find me at futureformed.io.

PS: Claude isn't the only horse in town, and all of this can be done with OpenAI Codex (ChatGPT), Google Gemini and many other AI apps.