You'd Never Build This in 2024

A few years ago, I would not have built this website.

That is not modesty. It is a practical statement.

I might have designed it in my head. I might have sketched the idea out. I might even have written a long brief explaining why a personal site should not behave like a normal personal site, and why each section should become a different kind of recognisable internet room. I would probably have described the homepage, the LinkedIn-style About page, the Guardian-style writing section, the Blogger-style personal blog, the Amazon-style book page, and the eventual MySpace-style projects area. I could have explained the logic. I could have defended the concept. I could have seen it.

But I would not have built it.

Not properly. Not quickly. Not with this level of specificity. Not as a non-coder with a job, a company, a book, a research corpus, a family, and the normal amount of life happening around the edges.

In 2024, this kind of idea would have been absurd for a personal website.

The old ways

I do not mean technically impossible. Almost nothing on the web is technically impossible if you have enough time, money, patience, and people willing to care about your very specific idea. But that is the point. The distance between "technically possible" and "reasonable for me to actually do" was enormous.

If I wanted to build this in 2024, I would probably have started with WordPress.

That would have been the sensible answer. Everyone knows WordPress. There are themes. There are plugins. There is documentation. There are people who can help. There is an established mental model. You want a personal site? Fine. Pick a theme, modify it, add a blog, maybe add some custom page templates, install a caching plugin, install an SEO plugin, install a forms plugin, install something to manage custom post types, install something else because the first thing conflicts with the theme, then spend the next week learning the difference between a block pattern, a child theme, and the thing you thought you changed but did not because the style was being overridden somewhere else.

And that is before the real problem begins.

A site like this is not one design. It is five or six committed designs sitting inside one site architecture. It is not "a homepage with some cards." It is a homepage with its own identity, an About page that behaves like LinkedIn, a writing section that behaves like The Guardian, a personal blog that behaves like old Blogger, a book page that behaves like Amazon, and eventually a projects page that behaves like MySpace. Each one needs its own navigation logic, spacing rules, typography, colours, layout conventions, footer treatment, and interaction expectations.

A WordPress version of this would not be a theme. It would be a theme family wearing a trench coat.

Drupal would have been more powerful, and probably even more punishing. You could do it. Of course you could do it. Drupal can model almost anything if you are willing to sit still long enough. But building a personal site like this in Drupal would feel like bringing a container ship to move a sofa. You would spend serious time establishing content types, view modes, templates, regions, libraries, routing, permissions, and deployment discipline before the site even began to feel like the thing you actually wanted.

The hiring problem

And if I had hired someone?

That would have been expensive, slow, and emotionally complicated.

Not because good designers or developers cannot do this. They absolutely can. But because the process would have required a level of shared obsession that is rare in a normal client engagement. I would have needed someone to understand not only what I wanted each page to look like, but why each page had to look that way. I would have had to explain that the LinkedIn page should not just nod at LinkedIn, it should pass the screenshot test. I would have had to explain that the Blogger page was not a generic retro blog, but a specific emotional reference point. I would have had to explain that the Guardian page needed to feel editorially credible without pretending to be a publication. I would have had to defend the Amazon page against looking like a joke, because the joke only works if the product page details are serious.

That would have taken weeks before the first version existed.

Weeks of briefs. Weeks of mock-ups. Weeks of revisions. Weeks of someone asking, quite reasonably, whether perhaps we should simplify the design system to keep things consistent.

And they would not have been wrong. In most projects, consistency is the right instinct. Reusable components. Shared tokens. One navigation pattern. One footer. One typographic hierarchy. One visual identity. Reduce complexity. Lower maintenance. Build the thing properly.

Except this site is not trying to be a normal design system.

The inconsistency is the point

Or more accurately, the contextual shift is the point. The site works because every section changes environment. The visitor does not just click into "About". They arrive somewhere that already has a social and professional meaning. They do not just click into "Writing". They arrive in an editorial frame. They do not just click into "Blog". They arrive in a warmer, older, more personal internet. The page is the context.

That is the kind of design decision that is easy to explain after the fact and difficult to build without losing nerve along the way.

What AI partnership actually looks like

Which brings me to the real point of this article.

I did not build this site because AI wrote some code.

That is far too small a description of what happened.

I built it because I had an engaged AI partner that could hold the concept, remember the decisions, absorb the corrections, inspect the existing work, propose alternatives, make technical choices, write code, revise code, debug errors, explain trade-offs, and keep moving with me at the speed of thought.

That sounds grand, but the actual working pattern was very practical.

I would say, "This page is not landing." The AI would propose options. I would reject the ones that felt wrong. It would adjust. I would show screenshots. It would analyse why the reference worked. I would clarify the principle. It would convert the principle into implementation. Then it would write the code, push the structure forward, and come back with something concrete enough for me to react to.

That is a very different thing from asking a chatbot for a snippet.

The value was not merely that the AI could produce TypeScript, CSS, and components. The value was that it could stay inside the design conversation long enough for the idea to become buildable.

The stack

The site became a Next.js project. Not because I woke up one morning desperate to have opinions about React server components, but because it was the right tool for a highly bespoke site that needed routed sections, page-specific styling, modern deployment, and enough structure to grow without turning into a folder of heroic HTML files. Tailwind v4 became part of the styling approach, with per-section CSS tokens where the platform homage required more precision. MDX was configured so writing can eventually move into a proper content workflow. GitHub became the source of truth. Vercel became the deployment path.

For a personal site, that stack is faintly ridiculous.

It is also wonderful.

I can work locally or through AI-assisted development. Changes can be committed to GitHub. Vercel notices the change and deploys the site. The infrastructure cost is effectively zero at this stage. The workflow is professional, but not heavy. It has the discipline of a modern software project without the overhead of a corporate delivery machine. There is no FTP client. No theme upload. No plugin roulette. No "this worked on staging but now the homepage is white." Just code, version control, deployment.

Speed changes ambition

That matters because speed changes the nature of decision-making.

When a change takes a week, you make fewer changes. When a design direction costs money every time it moves, you become cautious. When the person building the thing has to translate your vague dissatisfaction into tickets, you learn to ask for safer things. Eventually, the process shapes the ambition down until the idea becomes reasonable.

This build went the other way.

Because the loop was so fast, I could be more ambitious, not less. We could try LinkedIn properly. We could decide Substack was too subtle. We could research alternatives. We could test The Guardian as a better editorial frame. We could kill the professional/personal toggle when it became clear the distinction was weakening the site. We could keep the homepage as the controlled professional front door while letting the internal sections become more expressive. We could notice that every platform page needed its own navigation rather than forcing a single site nav across everything. We could debug CSS layering issues and turn that pain into a permanent rule.

The speed did not remove judgement. It increased the amount of judgement we could afford.

Speed is not quality — unless you are still choosing

That is the part people often miss when they talk about AI and quality.

The lazy version of AI work is obvious. Generate a page. Accept the first answer. Ship generic output. Pretend speed is the same as excellence.

That is not what this was.

This was faster because the collaboration removed friction from the translation layer. I did not need to become a full-time developer to express the thing. I did not need to wait a week to discover that a design choice was wrong. I did not need to compromise the concept because the implementation path looked awkward. The AI could move at implementation speed while I stayed focused on direction, taste, purpose, and fit.

That is the partnership.

What I am actually doing

I am not claiming I became a coder. I am still not a coder in the honest sense. I can read enough to be dangerous. I can understand structure. I can follow the logic. But I am not sitting there hand-crafting every component from first principles, and I am not pretending otherwise.

What I am doing is something different.

I am directing.

I am making product decisions. I am making editorial decisions. I am making UX decisions. I am checking whether the output matches the intent. I am rejecting things that are technically correct but conceptually wrong. I am pushing for specificity when the first answer is too generic. I am asking whether the page would be recognisable with the logo removed. I am holding the continuity of vision.

The AI is not replacing that. It is making that visible in production.

Why this matters beyond my website

That is an important distinction, because the site is not impressive because it was produced by AI. There is no shortage of AI-produced websites now, and most of them feel exactly like that. Smooth, competent, empty. The interesting thing here is that AI made it possible for a very particular human idea to survive the journey from thought to live website without being diluted beyond recognition.

That is new.

In the 2020s, we have talked endlessly about AI making things cheaper and faster. That is true, but not interesting enough. The more interesting point is that AI changes which ideas become worth attempting.

Before this working model, I would have filtered the idea before it even reached the build stage. Too much work. Too many templates. Too many edge cases. Too difficult to brief. Too difficult to maintain. Too indulgent for a personal site.

Now, the question is different.

Not "could I afford to build this?" Not "can I persuade a developer to care?" Not "which template gets me closest?"

The question becomes: can I describe the idea clearly enough, direct it carefully enough, and maintain the quality bar as it becomes real?

That is a much better question.

Why it suits how I work

It also suits the way I work. I think in systems. I tend to see the shape of things before I know exactly how to assemble them. I am comfortable iterating by elimination. I often know what is wrong before I can perfectly describe what is right. In an old build model, that can be frustrating for everyone involved. In an AI partnership, it becomes productive, provided the AI can hold context and keep up.

That is why this site feels like more than a personal project to me.

It is a proof point.

Not a proof point that AI can build websites. We are well past that. A proof point that a non-coder with a strong concept, a clear taste threshold, and an engaged AI partner can build something more bespoke than he could reasonably have commissioned, certainly more quickly, and possibly more faithfully to the original vision.

The irony

There is a strange irony in that.

The site itself is built around nostalgia. LinkedIn, Blogger, Amazon, The Guardian, eventually MySpace. Familiar rooms from different layers of the internet. The emotional memory of platforms. The comfort of known patterns. The older web peeking through the new one.

But the way it was built is entirely contemporary.

GitHub connected to Vercel. Next.js. Tailwind. AI-assisted architecture, coding, debugging, and editorial shaping. A workflow that would have felt implausible for a one-person personal site very recently, and silly to even attempt without either a budget or a development background.

That combination is what excites me.

Originality through familiarity. Production through partnership. Nostalgia delivered by the newest tools I have ever used.

The broader lesson

And perhaps that is the broader lesson.

AI does not make taste irrelevant. It makes taste more exposed. It does not remove the need for judgement. It punishes the absence of it. It does not magically create originality. It gives unusual ideas a shorter route to reality, which means the responsibility moves back to the person directing the work.

You still have to know what you are trying to make.

You still have to care when it is wrong.

You still have to say no to the version that is merely acceptable.

This site would have been a bad idea to build generically. It would have been a very expensive idea to build traditionally. It would have been a slow idea to build through conventional templates. But with the right AI partnership, it became a fast, practical, living project.

A few days from conception to deployed reality.

A free GitHub repository connected to a free Vercel deployment.

A personal site that behaves like a set of internet memories, each one doing a specific job.

And a reminder that the real shift is not that AI can make average things faster.

The real shift is that it can make unreasonable things reasonable, provided the human at the centre is still doing the work only a human can do: noticing, choosing, caring, correcting, and refusing to let the idea become smaller than it needs to be.