WordPress, then React, now Swift
For most of the last decade, “we need a website” meant “we need a WordPress build”. Nobody said the second part out loud. They didn’t have to.
That wasn’t a technical decision. It was barely a decision at all. It was just where the road went. A client would ring up wanting a site, and the question was never whether WordPress, it was which theme, which page builder, which plugin for the contact form. I built a business on that assumption and I’d make the same call again, because at the time it was the right one.
What’s interesting isn’t that it stopped being the default. It’s why.
WordPress won for a boring reason
It wasn’t the code. Let’s be honest about that.
WordPress won because it solved the problem nobody else was solving: a person who doesn’t write software can log in and change the words on their own website. That sounds small now. It was enormous. Before that, “can you update the opening hours” was an email to a developer and an invoice.
Everything else followed from that one thing. The plugin ecosystem, the themes, the hosting industry built on top of it, the fact that roughly half the web ended up running on it. None of that happens because the codebase is beautiful. It happens because a café owner in Didcot can change their menu on a Tuesday night without ringing me.
I still build on it. Most of what the agency does is exactly that: a client with a real business who needs to run their own site, day to day, without me in the middle. WordPress is still the right answer to that question, and I get slightly tired of people pretending otherwise.
Then the question changed
What shifted wasn’t WordPress. It was what people started asking for.
Somewhere along the line the briefs stopped being “a website” and started being “a thing that does something”. A quote calculator that prices a job based on twelve inputs. A dashboard that pulls from four APIs. A tool that needs to hold state, do maths, and not fall over when thirty people use it at once.
You can build that in WordPress. I have. It’s like building a shed out of a caravan: structurally possible, and you will think about it every single day for the rest of your life.
That’s where React and the rest genuinely earned it for me. Not because they’re newer or because there was a conference about them, but because an application is a different shape from a website, and they’re shaped like applications. Components that hold their own state. Types that tell you you’ve got it wrong before a client does. A build step that produces something you can actually reason about.
Quotify is where that properly clicked. Next.js, TypeScript, the lot. It was obvious within about a week that I wasn’t going back, for that kind of work.
Astro came later and is a slightly different story, because it went the other way: it let me take the things that were never really applications, like brochure sites, and stop pretending they were. I’ve written about that elsewhere so I won’t do it twice.
So I’ve got two defaults, not one
Here’s the bit I’d have found annoying to hear ten years ago.
This isn’t a ladder. I didn’t climb from WordPress up to React. I ended up with two tools for two different jobs, and the skill that actually matters is telling which job you’re looking at before you start. Most of the bad builds I’ve seen, mine included, come from picking the stack before understanding the shape of the problem.
The industry is quite bad at this. Every few years something becomes the thing, and a large number of people decide it is now the thing for everything, and then we spend three years discovering the edges of it. WordPress went through that. React went through that. Something you and I are both enthusiastic about right now is going through it as we speak.
Which brings me to Swift
I’m now writing a Mac app, which is not where I expected this to go.
My House, My Things is a record of a house: what’s in it, what it cost, what’s been done to it, when the boiler was last serviced. My first instinct was the stack I know. Web app, database, login, the usual.
Then I thought about what the thing actually is, and the web was the wrong shape for it.
It’s a record of a house, and a record of a house ought to outlive the software that made it. It holds what you own, what you paid and when the place is empty for a service visit, none of which needs to sit on someone else’s computer. A file you hold does both of those better than an account you rent.
Every one of those points away from a server and towards a file on your own machine. Once you’re at “a file on your own machine”, you may as well write a real app rather than a browser tab pretending to be one.
So: Swift.

It’s less of a leap than I expected
If you’ve been writing TypeScript, Swift is more familiar than it has any right to be. Strong static types. Generics that look roughly how you’d guess. Type inference that means you’re not writing annotations everywhere. nil handling that is essentially TypeScript’s strict null checks with better manners and a more insistent compiler.
Coming from a language where types were bolted on after the fact and can be lied to, there’s something quite satisfying about one where they were there from the start and can’t.
What doesn’t transfer is most of the rest. Value and reference semantics are a real thing again rather than something the runtime quietly handles for you. SwiftUI looks like React right up until it doesn’t, and the moment you assume it is React is the moment you lose an afternoon to a view that won’t redraw. And Xcode is Xcode; I’ll leave that one there.
But the shape of the work is recognisable. It’s the same job: model the thing properly, keep the state somewhere sensible, don’t make the user think about any of it.
The actual lesson, such as it is
Three defaults in about ten years, and the pattern is the same each time. The tool didn’t get better or worse. The thing being asked for changed shape, and the old tool stopped fitting it.
So I’ve mostly stopped asking what the best stack is. It’s not a useful question and the answer is always somebody’s preference wearing a lanyard. The useful question is what shape the thing is. A site people need to edit is WordPress. An application is a framework and a type system. A record that should still open in fifteen years is a file on a machine you own.
Get that right and the stack more or less picks itself. Get it wrong and no amount of tooling will save you, though it will absolutely give you something to blame.