My WordPress Development Workflow, 2026

Back in 2018 I wrote up my WordPress development workflow. I read it again the other day and, oof. Some of it holds up. Most of it is a fossil.

There’s no big story here. No dramatic “and that’s the day I rage-quit my old stack.” This is just a snapshot of how I build things in 2026 and the process that goes into it. Things have changed a stupid amount in eight years, and they’re still changing fast. So fast that this post will probably be wrong in six months. Maybe three. That’s kind of the whole point of writing it down: catch the thing while it’s still moving, before it moves again.

If you go read the 2018 version, you’ll notice almost every single tool got swapped out. The philosophy didn’t. I still like opinionated tools, I still build the same kinds of sites, and I’m still happy to be wrong in public. Let’s get to it.

The work itself barely moved

Before the tools, the work. That part hasn’t really changed. We still build a lot of LearnDash and LMS sites (the referrals keep coming, bless them), a steady stream of membership sites, and a healthy number of informational, brochure-style sites for businesses that just need something that works and doesn’t fall over.

LearnDash is still our LMS of choice. MemberPress still handles most membership jobs, and WooCommerce is still what we reach for when someone needs to sell. That bedrock is boring on purpose, and boring is good. It’s everything around it that got interesting.

Membership sites get their own stack

Membership is its own animal, so it gets its own treatment. MemberPress is still the engine for most of what we build there. It’s mature, it’s reliable, and when it comes to flexibility it’s honestly hard to beat. It handles the bulk of standard membership jobs without putting up a fight, and it bends when a client needs something stranger than the usual.

The part people forget is what happens after someone signs up. That’s where WP Fusion earns its keep. It sits between the site and the CRM and passes member data straight into ActiveCampaign (or whatever automation platform the client runs): tags, status changes, new signups, cancellations, upgrades, the works. A membership site that doesn’t talk to your marketing tools is leaving money on the table, and WP Fusion is how we make sure the right automations actually fire at the right moment.

AI is the new center of gravity

In 2018 there was no AI in my workflow. None. In 2026 it’s sitting close to the middle of almost everything I do, and I don’t say that as hype. “We use AI” is a meaningless sentence, so let me be specific about where it actually lives.

My editor is Zed. It’s a fast, modern code editor that happens to have agentic features baked in. I don’t use those. I use Zed as a plain, quick IDE and nothing more. And guess what? I don’t often use it. I’m mostly in the terminal anyway. Why? Because the actual AI work happens in exactly one place: Claude Code, in the terminal. That’s it. No copilots sprinkled across seventeen apps, no ghost-text typing over my shoulder. One tool, in the terminal, where I can actually direct it. An IDE for me is nice to have to quickly see different files when I need to, and to quickly look at code or docs.

So what does it do for me? A few things. It’s a planning device first. Before a project gets built, I run an intake step with Claude, and from there we can scaffold a build shockingly fast. It also talks to the tools I already use in a way that’s honestly profound, and that’s where most of the real speed comes from. And it’s brilliant for the small stuff: little one-off functionality plugins, quality-of-life fixes, the kind of feature request that used to eat an afternoon and now takes about an hour.

To keep it consistent, I lean on a set of skill files. I’ve got skills for building with Etch and ACSS, a skill for SEO audit and research (so I can pull extensive, consistent reports quickly), and skills for GridPane, plus GitHub and git config to wire up a GridPane site. I invoke the skill, and Claude already knows how we do the thing. I wrote about the design side of all this when we rebuilt our own site with Claude, if you want to see it in action.

Now the honest part, because nobody needs another breathless AI post. This is a power tool, not autopilot. Point it at something fuzzy, and it’ll confidently build you the wrong thing, beautifully. You still have to know what good looks like, and you still have to read what it wrote. The speed is real. The judgment is still yours.

Builders and CSS: Bricks today, Etch creeping in

For the last couple of years I’ve built primarily in Bricks, paired with Automatic CSS. Together they’re a genuinely killer framework and workflow that let me build fast and stay sane. I’m fully aligned with how the ACSS folks think about building: variables for everything, fluid wherever it makes sense, and an actual system instead of a pile of one-off rules. Once you build that way, going back feels like chiseling stone. It’s a big reason Bricks has stayed near the top of my page-builder rankings for a while. If you’re new to it, I put together a full getting-started guide for Bricks.

More recently: Etch. We are not fully switched over. We still build primarily with Bricks. But Etch has been proving itself, especially on simpler brochure-style sites, and I’ve been really impressed. digisavvy.com itself runs on Etch now, and that build was blazing fast for one specific reason: Etch is absurdly friendly to AI. If you want the long version, I wrote up exactly how we built it.

Why I left Pantheon (and where I landed)

Here’s the one that surprises people. I left Pantheon.

Let me be fair, because Pantheon is still a good host. Still a good product, still a good set of opinions. Everything I liked about it back in 2018 is genuinely still there. But I had a small number of clients I had to move off it, and the reasons stacked up. Silly little things at first: caching errors, LearnDash learner data not updating the way it should, and I couldn’t get traction fast enough to fix it. When a student’s progress data is wrong, that is not a small thing to the person whose course it is.

Then there’s the traffic thing. Pantheon measures how much traffic your site gets, and how they calculate it is still a bit of a black box. You can appeal it, but they aren’t exactly transparent about the math. What ends up happening is your customers are hit with a substantially larger hosting bill. And that sucks. I understand that their platform makes certain choices, and those choices cost real money to deliver. I respect it. But I’m not going to be penalized for a client’s success. We shouldn’t get punished for the site doing well, and that’s the part I couldn’t live with.

So we moved. For a while we were on SpinupWP, which I genuinely love. Their tooling is great, and honestly it stacks up well today. Eventually I landed on GridPane, because of a combination of things it offered that fit how I want to work. At the time it played nice with more hosting providers than the alternatives, and the big draw for me was multi-tenancy, which I really wanted to take advantage of.

More than any single feature, though, I just believe in the shape of it. Give me a management layer for the quality-of-life stuff, and let me provision my own bare-metal servers underneath. That combination wins on cost every time, and you get the best of both worlds: real control-panel tooling on top, rock-solid servers and support beneath it. And depending on your plan, GridPane will proactively monitor a site for you. If it goes down, they do the initial triage, tell you what’s up, and bring it back if they can. That, to me, is what “managed hosting” is actually supposed to mean.

Local dev and shipping

This part is refreshingly boring, which is exactly how I like my deploys.

I still build locally. Everything lives in Git and pushes to GitHub. From there, GitHub Actions deploys to GridPane, whether that’s the live site, a staging site, or an upstream. Need a staging environment? I spin one up straight from GridPane (you can lean on something like BlogVault for this too, but I usually just let GridPane handle it). Push the code, it ships. No drama, no migration-plugin gymnastics.

And yes, you should be using Git. If you’re a developer and it’s still not in your workflow in 2026, that’s the thing to fix this week. Not your editor theme.

The 2026 plugin shelf

The plugin list turned over almost completely. The headline change is WS Form. It’s so capable that it quietly replaced a couple of entire plugin categories on its own. If you upgrade one thing off this list, make it your forms.

The rest of the shelf, roughly:

• Advanced Custom Fields, still here, still doing the custom-fields heavy lifting.
• SEOPress for SEO. I moved off Yoast a while back and haven’t looked over my shoulder.
• Redirection, for exactly what it sounds like.
• WP Extended Pro, which rolls up a pile of little utilities I used to install one at a time: blocking user enumeration, changing the login path, user switching, that whole bag.
• Fluent SMTP for mail routing, pointed at Postmark. Clean, reliable, free.
• Fluent Snippets for code snippets. Here’s why I love it: snippets can live as files on disk instead of in the database. They also recently merged a pull request I sent them, so, thanks for that.
• Happy Files Pro, which gives the media library actual folders (the default library turns into chaos past about fifty images).
• Public Post Preview, so clients can review content before it goes live.

Then there’s the platform layer, which depends entirely on what we’re building: LearnDash for LMS work, MemberPress for membership, WooCommerce when there’s a store, and WP Fusion tying member and customer data back to the CRM. Those four are the load-bearing walls. Everything above them is trim.

A bunch of 2018 regulars didn’t make the cut. Stop Emails, Duplicate Post, What The File: gone. For admin menu cleanup, I’m still running Admin Editor Pro (still a world-beater, that plugin), but I’m probably about to swap it for a little menu-management plugin we built ourselves.

Which brings me to the real shift in how we handle plugins. More and more, when we need a bit of functionality, we just build the plugin. Small, single-purpose, ours. AI made that cheap enough that it’s often faster than finding, vetting, and learning to trust someone else’s. I dug into that little internal apps habit over here and showed off the ones running our own site. And if you’re sweating your plugin count, I’ve got thoughts on that too.

We make our own tools now

That habit scaled up. We’ve started building actual add-ons for the Etch ecosystem. There’s Drawers, a small set of drawer components, and Ledger, a version-history tool for Etch. They’re modest today, but Ledger especially is something we’ve got real plans for.

Eight years ago this post was mostly about which frameworks I borrowed from smarter people. These days, as often as not, we’re the ones making the thing. I did not see that coming, and I kind of love it.

So, what are you using?

That’s the stack as of today. By the time you read this I’ve probably already changed my mind about something on it. That’s the job. The tools are going to keep moving, fast, and the best any of us can do is stay curious and keep building. (If you want my wider read on where WordPress is headed in 2026, I got into that separately.)

So I’ll ask you the same thing I asked back in 2018: what are you all using these days? What did you drop, what did you fall hard for, what’s the one tool you’d rip out of my hands if you could? Leave it in the comments. I actually read them.

And if your site is the thing that keeps falling over and you’d rather hand the whole stack to someone who does this all day, well, that’s literally the job.