How I Replaced Wix

I've been diagnosing other people's products for long enough that it's basically automatic. It took an embarrassingly long time to apply the same thinking to my own content stack.

I have a professional habit I can't seem to switch off.

When I work with a product, I start diagnosing it. Not aggressively — just noticing. Where are the friction points? What was added without thinking about the user? Where has the team clearly run out of conviction and started bolting things on?

I've been doing it for long enough that it's basically automatic. And for a long time, I did it everywhere except my own content stack.

My Wix site had been quietly becoming a mess for years. I'd started with a template, which is always how it begins. And then I'd customised it — a widget here, a layout adjustment there, a workaround for the newsletter integration that wasn't quite right. Each change made sense in isolation. Together they'd created something that looked like a website but functioned like a patchwork. Every time I wanted to change something, I had to unpick three other things to get there.

This is the Wix Frankenstein problem. Once you've wandered far enough from the original template, you're no longer using a platform. You're maintaining a bespoke arrangement of someone else's constraints. The seams start showing and you can't really hide them anymore.

The features weren't helping. Wix has added a lot of things over the years. Whether those things were added because users needed them, or because a product team needed to show growth on a roadmap, I genuinely can't tell. What I can tell is that the experience of using them rarely felt like someone had thought carefully about what I was actually trying to do. SEO fields had to be filled in manually, one field at a time, no intelligence, no suggestions, no memory. The newsletter tools required a separate login and a separate mental model and a separate sense of where everything lived. Each feature worked in isolation. Nothing worked together.

At some point I sat down to write a post and realised I was spending more time fighting the interface than writing. That's the moment I should have acted. I didn't. I wrote the post, closed the tab, and told myself I'd sort it later.

Later arrived when I was reviewing a product for a client — a B2B tool that had grown the same way. Good bones, genuinely useful core, but years of accreted decisions that had never been reviewed together. Features that contradicted each other. Defaults that made sense once and hadn't been revisited. A growing list of things that required workarounds. I wrote up the diagnosis, presented it to the leadership team, and on the drive home realised I was describing my own website.

That's the thing about seeing the same pattern in someone else's product. You can't unsee it in yours.

I decided to treat it the same way I'd treat any product problem. Define what it actually needs to do. Be honest about what it currently does. Build something that closes the gap.

What I actually needed was quite specific. A clean writing environment that got out of the way. A CMS I controlled, with fields that made sense for my content. An AI formatting layer that handled the tedious parts — SEO fields, excerpts, structural markup — without requiring me to prompt it every time. A newsletter that looked the way I wanted it to look and sent when I told it to. Music embeds for the album posts. Collections for grouping content by theme. A way to write in development and push to production without a deployment ceremony.

I built it in two weeks, on Replit, with AI assistance. Not because I'm a developer — I'm not — but because the AI tools have moved to the point where someone who thinks clearly about products and can articulate what they need can actually build working software. I'd describe what I wanted, review what came back, push on the parts that weren't right, and iterate. The same process I use when I'm working with an engineering team, except faster and with no scheduling overhead.

The result is this site. Custom CMS, proper collections, AI-assisted content formatting that runs on publish, a newsletter that sends exactly what I specify and looks like it belongs here. No Frankensteining. No workarounds. No features I don't use.

What surprised me wasn't that it worked. I'd expected it to work, more or less, with enough iteration. What surprised me was how much I'd been tolerating without noticing. The friction had been so consistent that it had stopped registering as friction and had started registering as just how this is.

Owning the platform changed that. When something doesn't work the way I want it to, I can change it. When I want to add something — a feature, a field, a formatting rule — I can add it. There's no negotiating with someone else's product vision. It's just mine.

I think there's something worth saying here for other people who work in product. We're quite good at diagnosing problems in systems we're responsible for. We're often much slower to apply the same thinking to the systems we depend on. Partly because the cost of changing them feels high. Partly because we've normalised the friction.

But the cost of staying is real too. It's just spread out thinly enough that you don't notice it until you add it up.

Two weeks, start to finish. I have a blog I actually want to write on now.