Endlessly Fascinating
I’m sitting at this WordPress meetup, and we’re chatting about the latest trends in theme development from the past year — everything from the state of page builders to new animation tricks, effects, and, of course, our shared disdain for Gutenberg.
Everything’s going great until that one guy — you know, the hippy code purist — joins in. He starts preaching about how we should be “crafting” our themes from the ground up using _underscores.me or whatever, that plugins are evil, and that “actually,” we shouldn’t use builders at all because they’re not compliant with some obscure best practice. Cue the collective tune-out. He talked for five minutes straight while the rest of us mentally checked out.
Then there were a few agency folks in the mix too who surprised me with offhand comments about how they use a different theme for every single client project. Clearly, these weren’t developers — more like designers who discovered WordPress, WP Engine’s one-click installs, and the theme gallery.
These two kinds of WordPress users always fascinate me. And I can’t help but think: web developers are endlessly creative when it comes to finding new ways to go broke.
The Backstory
Over the past 25 years, I’ve built and launched somewhere around 250 WordPress sites. Right now, I’m running five servers that host 143 active sites — all quietly humming along, with only the occasional script hiccup or form delivery glitch to keep things interesting.
We launched three new sites last month, and I’ve got four more lined up before the year’s out.
And here’s the part that usually gets a reaction: I use the same theme for every single one.
Dramatic pause.
Let me explain.
Back around 2000, I was still hand-coding websites when I stumbled across this thing called a CMS. Not WordPress—Drupal. And later ExpressionEngine. Both were just clunky enough to convince me I should build my own PHP-based content management system. So I did, and for a few years I bounced between my own creation and whatever other awkward tools were floating around at the time.
Then someone mentioned WordPress.
I started using it back in the beta days—then Version 1. At first, WordPress wasn’t great. It felt like a strange little blogging tool with a clunky interface. But that didn’t last long. Over the next few years it suddenly grew pages, themes, plugins, even an ecommerce solution.
Fast-forward twenty years, and it’s the only platform I’ve used since.
Reuse – Recycle
At its core, WordPress is really about building a theme and then wrapping the content around it. A couple dozen projects into my WordPress journey, though, I hit a wall—three brutal builds in a row. One of them was a bridal shower site, and the theme the client loved didn’t have the features of another theme they also loved. Back in 2008, getting themes to do anything outside their default behavior required heavy customization, and it was a constant tug-of-war.
Around that time, I went to a developer meetup and talked to a friend who told me they’d stopped picking themes altogether. Instead, they found one solid theme they liked and customized it relentlessly—adding every feature they could imagine and every layout option they needed as projects came along. Over time, they ended up with this Frankenstein starter theme packed with options right out of the box. No reinventing the wheel, just massive time savings.
The motto was simple: reuse and recycle.
That’s probably what pulled me into the _underscores.me rabbit hole, too. I figured I could build my own “one theme to rule them all,” keep layering in functionality, and maintain a repository with the latest version ready to deploy for any new project. But what I discovered was that technology evolves fast—scripting languages shift, mobile responsiveness becomes mandatory, design patterns change—and the web landscape transformed so quickly over the next 5–7 years that keeping one master theme perfectly maintained with a small team became nearly impossible.
Development time was being saved, but time going into supporting and maintaining the stack had crept to a frustratingly high non-billable time suck.
Your A What Agency?
It was maybe around 2016 at a WordCamp in Grand Rapids, Michigan when I first heard someone talk about being a “BE Agency.” A year later, I heard the term “Avada Agency.” These were teams of in-house developers who built every project on a single theme—either BE or Avada. Both themes were backed by large third-party developer communities, loaded with effects, layouts, and customization options, and consistently updated and supported.
With either theme, you could build a thousand sites and not have two look alike.
It was a dream come true, and I instantly understood the appeal.
Pick Your Stack
After playing around with the Betheme and Avada theme, and then trying the big stand alone editors like VisualComposer and Elementor, I landed on a theme called Salient. I’ve learned to hack and customize this particular theme and can bend it to my will for any project or look imaginable. The license is reasonable and the learning curve isn’t that steep. Plus added benefits of built-in SEO tools, and the ease of schema is also a value add.
I find that if I want to use pure HTML or PHP, I can. If I want to just change the look with CSS or have a couple good CSS developers jump into the project, it’s easy to change the look. If I want to hand it off to a client, and they want to use a visual builder because thats easier, I can do that too. Yes it’s a “theme”, but ultimately it always ends up custom.
But most importantly, I’m not starting from scratch on every project.
That’s the real takeaway here. If you’re a long-term developer, managing a team of designers who’ve turned into armchair web devs, or you’re a solo operator—stop wasting valuable, billable time chasing new themes or reinventing the wheel on every build. Pick one stack you can get really good at—one that covers at least 95% of your project needs. Then commit to it. Train your team on it. Get fast with it.
Let’s be honest: most clients can jump on Wix or Squarespace and spin up a box site for a couple hundred bucks a year. Your job is to make your pitch strong enough that they don’t choose that garbage—but also to lower your internal costs so you can be competitive if needed. That’s your edge. Once your entire team is aligned on the same stack, development time drops dramatically, and suddenly “rapid development” isn’t just marketing fluff—it’s real. Another bonus? Anyone on the team can jump in and help because everyone’s working with the same tools. (This applies to dev and design software, by the way—but that’s a rant for another post.)
Some practical tips for making this workflow actually work:
- Keep a running list of customizations and hacks for your chosen theme. I’m on a Mac, so Notes.app is one of my most valuable tools. Every CSS tweak or custom function goes in there—and because it’s searchable, I can find anything in seconds.
- If you want that knowledge to be searchable and shareable, learn to comment your code properly. Explain what it does, where it goes, and when it was last modified. Keep the comment in your notes, then copy both the comment and the code into your functions.php or stylesheet for consistency.
- Choose a theme with WooCommerce baked in—and then learn to bend WooCommerce to your will. I can’t stress this enough: WooCommerce is a beast. Learning to customize its output via functions is worth its weight in gold. Product views alone will eat more development time than almost anything else if you’re not prepared.
- Stop doing paper mockups and start asking for benchmark sites. Designers can burn more billable time obsessing over unrealistic mockups than the rest of the project combined if you let them. I haven’t done a mockup in 15 years—and neither should you. Keep designers focused on what they’re best at: logos, icons, and brand guidelines. Let developers build from benchmarks, provided assets, and how far the theme can be pushed to prototype the intent. “Responsive reality” and “functionality compromise” are real things. I’ve seen entire projects derailed because a pixel didn’t perfectly match a mockup.
- Finally, once your team truly understands what your chosen stack can—and can’t—do, something magical happens: scope creep dies down. The daydreaming, over-promising, and “what if we just…” ideas that drive developers into silent rage start to disappear. Everyone gets on the same page, expectations level out, and projects actually ship.
