Rebuilding Arsmedia.co.uk: From Base44 Prototype to a Maintainable Stack

I did not rebuild arsmedia.co.uk in one clean sprint.

It was messier than that. More like a few different approaches slowly collapsing into something I could actually maintain without dreading it.

That turned out to be the real project.

For a while, the site lived in that familiar in-between state: good enough to keep using, not structured enough to trust long term. It worked. It looked decent. It also carried the quiet instability of something that had grown faster than its foundations.

This rebuild was less about a dramatic redesign and more about turning a prototype into a system.

Phase 1: The Base44 Prototype That Stayed Longer Than Planned

I started with Base44 and built a prototype.

To be fair to it, the result was better than I expected. The output looked polished quickly, the site did what I needed, and for a while that was enough. Like many prototypes, it was supposed to be temporary.

It was not.

It just stayed there, quietly doing its job as a static page that looked good enough and did not create enough pain to force a rebuild. That is how a lot of "temporary" things become semi-permanent.

I had already written something similar in my Base44 review, and I still think it is true: Base44 is genuinely strong at getting you to visually good output fast. The problem comes later, when you want to organize that output into a codebase you can keep working on with confidence.

That later part eventually arrived.

At one point, I also tried a redesign using Google Stitch. I did not ship that version, but I kept one useful artifact from it: the design.md file.

That file mattered more than the design itself.

The mockup did not make it into production. The spec did.

Phase 2: Moving the Project Into GitHub and Replit

The next step was getting the site out of one-off prototype territory.

I created a GitHub repository from the Base44 output and committed the project properly so it stopped living like a fragile artifact. From there, I pulled the repo into Replit and decided that this would be the actual working environment going forward.

That decision changed the feel of the project immediately.

It stopped being "that page I made a while ago" and became something I could iterate on through a real workflow. Replit was not just a place to tweak things. It became the place where the rebuild actually happened.

Inside Replit, I brought in the design.md file from the abandoned Google Stitch redesign and used it as a living spec. I did not copy the visual direction one-to-one, but I used the rules inside it as constraints: layout, spacing, typography, section flow, and how the page should feel as it stacked.

That helped more than I expected.

Without a spec, it is easy to drift into browser-side tinkering and call it progress. With one, the work gets quieter. Less guessing. Fewer random detours.

Specs travel better than screenshots.

Phase 3: Cloudflare Pages and a Real Deployment Flow

Then the infrastructure needed to grow up a bit too.

I moved the project into a cleaner setup:

• Replit for writing and editing code
• GitHub as the source of truth
• Cloudflare Pages for builds and deployment

It is not an especially glamorous stack. That is partly why I like it.

It works.

The flow is simple: I edit in Replit, commit and push to GitHub, and Cloudflare Pages deploys from the repository. That alone removed a surprising amount of friction.

No more wondering where the latest version lives. No more half-finished prototypes floating around. No more uncertainty about which version I am actually editing.

The site finally had one path from code to production.

That sounds basic, and it is. But if you have ever lived inside scattered tools and duplicate versions, you know how much clarity a simple deployment path creates.

Phase 4: Cleaning the SEO and Site Structure with Claude

Once the stack was stable, I used Claude inside Replit to clean up the SEO foundation and structural inconsistencies that had built up during the prototype phase.

This was not about chasing clever SEO tricks.

It was about making the site internally coherent.

We worked through things like URL structure, page naming, content hierarchy, metadata, and on-page elements that had drifted over time. The goal was straightforward: make the site easier to understand for both humans and search engines.

That meant creating sections that made sense, URLs that actually reflected what a page was, and content blocks that did not force the reader to guess how the site was organized.

There is nothing flashy about this kind of cleanup. Still, it changes how solid a project feels. A site does not need to be huge to benefit from better architecture. In some ways, smaller sites benefit even more, because every inconsistency becomes more visible.

What I Learned from the Rebuild

A few honest lessons came out of the process.

Base44 is a strong starting point, not a long-term home

I still think Base44 is impressive. It is fast, visually competent, and useful for getting momentum. That matters. Sometimes speed is the difference between shipping something and endlessly planning it.

But when a project needs longevity, structure starts to matter more than first output. That is where the tradeoff becomes obvious.

For me, Base44 was a very good beginning. It was just not the place I wanted the project to live forever.

Documentation matters more than it feels like at the time

Saving the design.md file from the Google Stitch experiment turned out to be one of the best decisions in the whole process.

The design itself did not survive. The documentation did.

That is worth remembering. Screenshots are easy to admire, but documentation is what helps a project move from one environment to another without losing its shape.

A spec gives the work continuity.

A real workflow changes your relationship with the project

Once the site lived in GitHub, Replit, and Cloudflare Pages, it stopped feeling fragile.

That psychological change matters more than most people admit. Some projects do not stall because the idea is weak. They stall because the environment around them feels temporary, messy, or too easy to break.

A cleaner workflow makes iteration less emotionally expensive.

And that means you actually return to the work.

Claude plus Replit is not magic, but it is useful

This is probably not the fastest route on paper. It is definitely not the cheapest.

Still, it is working for me.

What I am getting from it is not magic generation. It is assisted cleanup. Better structure. Better naming. Better continuity between what I intend to build and what is actually in the repo.

That is less cinematic than the "one prompt builds the app" story, but it is more useful in real life.

I am gradually straightening the project out: tightening the structure, cleaning the SEO layer, fixing naming, reducing friction, and getting the codebase to a place where touching it does not feel risky.

That is real progress.

The Recommendation

If you can afford the extra time and cost, document your project properly before you try to scale it with AI.

Then use an AI assistant inside a real development surface, not only inside a chat window.

That has been the biggest lesson here.

The fantasy is still one perfect prompt that generates the whole thing. Maybe that will happen more often over time. Right now, though, the more durable path looks different: document the system, move it into a workflow you trust, and then let the model help you improve it step by step.

It is slower.

It is also more yours.

I still have not fully brought Claude Code into my workflow, and I am curious about what changes when the assistant moves even closer to the codebase. Part of me suspects it would speed up some of this. Part of me suspects it would just change where the mess appears.

Either way, this rebuild clarified something useful:

Good prototypes are easy to admire. Documented stacks are easier to live with.

---

If this was useful, these are worth reading next:

• Base44 Review (2026) -- on what Base44 does well and where it falls short for production work.
• Google Stitch 2.0 Review -- a closer look at the tool whose design.md outlived the mockup.
• The Creator AI Stack I Actually Use in 2026 -- how these tools fit into a broader workflow.