The tech stack behind every website I build

“What do you actually use?” is the question I get most, from other developers and the odd curious client. It’s a fair one. The tools are the workshop, and mine has been refined over years of building, breaking, and quietly swearing at things until they behaved.

So here’s the honest answer: the whole lot. Not a sponsored top-ten, not the trendy stack of the month, just the actual tools I reach for, day in, day out.

There’s a catch, though. I do two quite different kinds of work, and they need two quite different toolkits. Most clients want a WordPress site, and WordPress is genuinely brilliant at that. But some projects aren’t a WordPress job at all. They’re bespoke web apps, and those get built on a modern JavaScript stack. So this splits neatly down that line, with a handful of tools I use no matter what’s under the bonnet.

Let’s start with the bread and butter.

The WordPress stack

Hosting: 20i, and a cloud setup for WooCommerce

The majority of client sites live on 20i. It’s fast, UK-based, properly good value, and the support actually knows its stuff. Once you’ve waited 40 minutes for a first-line script-reader elsewhere, you learn not to take that for granted. For a standard business site it’s the easy choice, and it’s where most of the sites I host sit.

WooCommerce is a different animal. A busy shop asks a lot more of a server, and shared hosting starts to creak. So those go on cloud: a Vultr High Frequency instance, managed with FlyWP, running OpenLiteSpeed as the web server. Vultr gives me genuinely quick hardware for the money, FlyWP turns a bare server into a tidy managed host without me living in the command line, and OpenLiteSpeed handles the traffic far more gracefully than vanilla Apache. It’s more moving parts, but for a shop that’s making money it’s worth every bit of the extra speed.

Managing it all: MainWP

Look after enough sites and “log in, check, update, repeat” stops scaling. MainWP is my answer: one dashboard for updates, backups and security across every site I manage. The bit that matters to me is that it’s self-hosted, so all that client data lives on my infrastructure rather than a third party’s. No affiliate link on this one, for the record, since they don’t run a programme. I recommend it because it’s quietly indispensable.

Building: Bricks or Blocksy, then Stackable

There are two routes here, and which one I take depends on the project. When a build needs really granular control over the design, I reach for Bricks. It’s a theme-based visual builder that hands you near-total command of the layout and the markup, with clean output that flies on Core Web Vitals. The trade-off is time, because all that control means more hands-on input. Here’s why I switched to it.

For a simpler site that needs to look great and stay easy to manage, Blocksy is the better call. It’s a lightweight, flexible theme that’s brilliant straight out of the box and a doddle to configure. The full story is here. On top of Blocksy I’ll usually add Stackable, which extends Gutenberg with extra blocks for more design control without reaching for a heavier builder. More on that here.

One thing worth being clear on: it’s Bricks or Blocksy, not both. Bricks replaces the theme, so the two are alternative approaches rather than a combo. Bricks when you want bespoke control, Blocksy (plus Stackable) when you want a fast, tidy, easy-to-run site.

The essentials: forms, bookings and speed

A couple of plugins go on almost everything. Fluent Forms for forms, because it’s fast, modern, and doesn’t drag the page down (review). Fluent Booking when a client needs bookings handled natively in WordPress, with no third-party platform required (review).

For speed, WP Rocket is fantastic. It’s the easiest performance win you can buy, doing the right things by default with barely any fiddling (review). That said, where the server supports it I’ll usually advocate caching at the server level instead, with something like LiteSpeed. It tends to be faster, it’s one less plugin to keep an eye on, and it pairs neatly with the OpenLiteSpeed setup above.

The custom-build stack

Sometimes WordPress genuinely isn’t the answer. A web app, an unusual data model, something that needs to do real work rather than publish content: bend WordPress into that shape and you’ll fight it the whole way. For those I build bespoke on a modern stack. None of these carry affiliate links. They’re simply what I use, and the half of the job that backs up the strategy and custom work.

The foundation: Astro, Next.js and TypeScript

Astro is my default for anything content-led, like marketing sites, blogs and fast static pages (this very site runs on it). It ships almost no JavaScript by default, which is exactly what most sites should do. When a project is genuinely an application, with dashboards, logged-in areas and real interactivity, I reach for Next.js. And it’s all TypeScript, always. The upfront discipline of types pays for itself the first time a refactor doesn’t quietly break three things you’d forgotten about.

Styling: Tailwind

Tailwind gets a lot of stick from people who haven’t lived with it. I’ll defend it. Styling in the markup keeps everything in one place, the design stays consistent because you’re working from a set scale rather than inventing margins, and there’s no sprawling stylesheet slowly rotting in the background. It just works.

Data and backend: Neon, Supabase and Prisma

When an app needs a real database, my go-to these days is Neon. It’s serverless Postgres that’s genuinely easy to work with and flexible enough to scale with the project. I’ve used Supabase plenty too, and it’s great when you want auth and storage bundled in, but for the database itself Neon is the one I keep reaching for. I talk to it through Prisma, which keeps queries type-safe and the schema version-controlled like everything else, rather than living as tribal knowledge in someone’s head.

Auth and payments

For authentication, Better Auth has become my pick, especially paired with Neon. It’s modern, flexible, and handles the part nobody should be hand-rolling in 2026. Auth.js still does the job well if a project suits it better. When money changes hands it’s usually Stripe, whose docs and API set the gold standard. I’ve also built on Paddle, which is the better fit when a merchant-of-record setup makes sense and you’d rather it handled the sales-tax headache for you.

The glue: Trigger.dev and Resend

The unglamorous, important bits. Trigger.dev runs background jobs and long-running tasks, the work that shouldn’t block a user or time out a request. Resend sends transactional email that actually lands in the inbox, with a developer experience that makes most legacy email providers feel like a chore. Both are the kind of tool you forget about precisely because they don’t cause you grief.

Where it runs: Cloudflare and Vercel

Astro sites and anything edge-first go on Cloudflare, which is fast everywhere, sensibly priced, and hard to beat on the wider platform (DNS, caching, workers). Next.js apps usually land on Vercel, where they’re built to run and the deploy experience is frictionless. Right tool, right home.

Whatever I’m building

A few tools don’t care which stack I’m on. They go on everything.

UptimeRobot watches every site and tells me the moment one falls over, before the client does (review). Plausible handles analytics. It’s privacy-first, cookieless, lighter than GA4, and it skips the cookie banner entirely (review). Cal.com runs my own bookings (review). And Termageddon keeps legal policies auto-updating so they stay compliant instead of quietly going stale (review).

The two I built myself

When the right tool didn’t exist, I built it. Quotify is my no-code quote and estimate builder, and it turns website enquiries into booked jobs. SendTidings sends beautifully designed monthly client reports on autopilot, so I’m not rebuilding the same PDF every month. Dogfooding at its most useful: I use both, every week.

The point isn’t the tools

Here’s the thing I’d leave you with. None of this is a league table. There’s no single “best” host or builder or framework, whatever the listicles tell you. The skill isn’t in owning the trendiest stack. It’s in knowing which tool actually fits the problem in front of you, and being honest enough to reach for WordPress on one project and throw it out entirely on the next.

That’s most of what working with me is: the right tools, used well, with no dogma about which camp they come from. If you’d like a site built on a stack that’s been chosen on purpose rather than habit, let’s have a chat.