First and foremost, PeakZebra is a SaaS offering. It’s the familiar online model, where you pay monthly, except maybe I’ll do what it seems like everyone else is doing these days and force you to pay for a year (which, even if I wind up doing it, I hate).
But there’s a second layer, where you can, if you choose, pay for individual tweaks to the applications you’re using (well, tweaks right up, theoretically at least, to wholesale creation of full-blown new apps). The model here is what’s been called “productized services,” which is an odd name but one that does manage to convey a sense of the value proposition, which is that you pay a controlled and fixed amount for your use of what otherwise might have been charged on a project or hourly basis.
Agency?
The “thing” you get from PeakZebra is a customizable website, so another way of thinking about this is to call it an agency. But it’s really not an agency in the traditional sense where you show up and request a customer-facing site that represents and explains your business to the internet.
Why do I care what to call the business model? I only care because I want a quick way to communicate what’s on offer. “Internal tool agency” doesn’t do it for a few reasons, I’d say.
Oh, and it seems obligatory that I convey the idea that AI is involved, because that seems to be the only thing that anyone is paying attention to in new products and services these days. I noticed just now that Airtable’s H1 is now “Digital Operations for the AI Era.” To be honest, this makes me instantly just the tiniest bit suspicious. And to be fair, it’s not like I even know what it is that they’re using AI for.
AI Magic Broker?
The irony is that I do absolutely plan to be using AI behind the scenes (as per several blogposts by now), but I’m actually more inclined to be relatively quiet about it. It’ll make things fasters for developers handling requests, but the key point is that there’s an actual developer involved.
So maybe I focus on it being a SaaS for ad-hoc apps, but a subscription that makes it seamless and easy to mold the app to your needs. If you have a real management job already, you might very well be not even the least bit interested in spending time learning how to do this and that in Airtable or Notion (or pick some other preferred magic no-code SaaS).
Maybe “guided low-code automation at a fixed subscription price.” OK, that’s too long, so maybe “subscription app refinement.”
Low-code Whatever
Actually, I hate that one. I still have some noodling to do on this, I guess. I think getting it right will give me greater clarity when I try to tell people what the “thing” is that should grab their attention about PeakZebra. Sure, it’s a way to pay for the world’s least-featured CRM, but there’s a little more to it than that.
People have made some very impressive business successes by offering non-free plugins and plugins that are extensions to other plugins that are big enough to have extensions of their own (WooCommerce being the primary example). But I think it’s increasingly unlikely that this is a good way to launch a successful business.
[Since originally writing this, it’s also occurred to me that the agency approach to making a living in the WordPress space may also be living on borrowed time. That’s because high-end website owners and their agencies may opt to avoid the perceived risk of WordPress coming unglued and may in any case prefer different architectures while, at the same time, lower-end sites (blogs for authors and the like) are increasingly very well served by “drag and drop” sorts of offerings. I’m thinking of website builder SaaS offerings, certainly, but also platforms like Substack and Patreon. If my goal was to create a subscription newsletter, I wouldn’t presently choose a WordPress site if I wasn’t already very familiar with WordPress.]
I’m thinking primarily of bootstrapped businesses, but I also suspect that bootstrapped startups may be all there is in the WordPress space, at least for a while, because Matt Mullenweg’s takeover of Advanced Custom Fields (and his subsequent takeover of parts of the premium version of ACF) has, I’d imagine, significantly cooled the enthusiasm of venture capital investors for premium plugins.
In the bootstrap world, there’s probably less reason to fear that some Matt out there will steal your goodies, but that doesn’t mean someone else couldn’t. The ACF heist was a poignant reminder that you really don’t own your own code in the world of open source (which, come on, was the whole point of open source in the first place, so don’t act shocked).
As I write this, there’s more of a serious movement afoot to revise WordPress governance so that it’s more of a community driven project (instead of a one-guy project that has a huge community). But who knows how that will play out.
SaaS as a solution
As I’ve mentioned elsewhere, one approach that protects whatever secret sauce you bring to the meal is keeping the sauce on the server side of a SaaS offering. For a lot of plugin builders, the trick will be simply not to package the plugin as a plugin.
But I think there’s another issue, and I even think it’s one of the inherent strengths of open source as a concept: over time, free versions of things get better and better. You may have a feature-laden free version and a whole bunch of great goodies to hold in reserve for the premium version, but over time you’ve going to see other developers make competing products that offer some of your premium features for free.
Freemium limps along
I don’t mean to say this kills the freemium model, only that the tendency is toward making the premium side of the equation less valuable over time. Given that pricing in the WordPress ecosystem is arguably too low, this seems likely to make would-be entrepreneurs not exactly thrilled to jump in with both feet.
This is too bad, because there’s nothing quite like the WordPress plugin ecosystem (or the theme system, for that matter) out there in the software world, and it’s offered a way for a lot of smaller businesses to get a foothold and make a go of it. Not to mention creating ways to create all sorts of non-business blogs and the like.
But I think this shrinking premium benefit phenomenon is inherent in current-day WordPress and open source. There’s less and less incentive to spend a year rolling out a paid plugin. If you win, you don’t necessarily win much, your potential winnings aren’t secure, and competition from free alternatives is going to slowly erode your niche.
Will the wolf survive?
So do people like me stick with WordPress? Well, if we’re specifically looking at my case, then yes. I stay in WordPress, trying to leverage opportunities that take advantage of the platform’s enormous market share without getting bitten by the current growing risks to WordPress business.
(I will say I’m tempted to just switch up and go full time on whatever Joost and company wind up concocting–but that too will be WordPress in some form or fashion.)
I’ve got to believe that when a framework on the Internet has 40% market share, there’s still lots of opportunity to supply things people need, even if it’s a smooth, easily understood offramp from WordPress.
All that said, though, I’m still inclined answer the question I started with–is the plugin business played out?–by conceding that, yes, it may well be.
You hear a lot of blather about what the “minimal” in Minimal Viable Product means. And YCombinator has made an industry out of reminding people to launch before they think they’re ready. The trick of course is figuring out where this does and doesn’t apply without kicking the fledgling from the nest while the poor chick is still featherless.
So I’m preparing to launch PeakZebra in a matter of a handful of weeks, have a list of things that have to get done before that launch can happen, and realized just a couple days ago that the list contained a whole subsection (requiring substantial work) that I can cut without impacting the product release at all.
Extra work for fun and profit
I want to share some of the specifics of this discovery because, for all the MVP blather, there aren’t that many useful examples of actually making decisions around just how much P is needed in an MVP. This is also a case where what I’m eliminating doesn’t really have much to do with the product (at least as it’s released).
Like any SaaS, I need a self-service signup process for new customers. In the particular case of PeakZebra, the way I want to handle that is by having a WordPress site dedicated to the process of signups, billing, and account management. The product itself resides in multiple instances of WordPress with the necessary functionality preloaded into them.
I spent perhaps half a day thinking about what I’d need on the signup site, debating using an existing third-party plugin (a SaaS subscriber is pretty much the same thing as a “member”, so plugins that handle paid memberships come to mind). I spent a couple hours wondering what should be on the front page of this site.
Admin can wait
But then, enlightenment. I don’t need any of this to launch. For early access, I’ll have a form on PeakZebra.com (and yes, this will be a PeakZebra form) and I’ll enter the necessary data in Stripe by hand.
I’ll need the signup site later, particularly as clients start wanting to manage their account information. I’m kicking a can, but it’s clear to me that none of the work on this should happen before the service itself is feature complete and out in the world with a few customers.
If this were going to be a high-volume, consumer-facing business, I couldn’t have made this particular choice.
And by way of counterexample, I’m not foregoing simple onboarding help out past launch. I think “ease of entry” is absolutely crucial to the PeakZebra experience. I’ll keep it to the bare minimum, but the bare minimum is somewhere above the zero mark.
For every decision to tackle something prelaunch, I need religiously to ask myself: “Why do I need to do this before I have customers?”
As I was writing this, Joost de Valk posted a blog piece that points out three key areas of weakness that confront WordPress and rightly points out that we had better face these concerns head on and clear eyed. We need as a community to have the discussions that lead WordPress by developing a vision for it.
To me, it feels like the current Matt vs. WPEngine drama was a tipping point, even if the problems deValk highlights existed well before. That’s because all of the businesses that primarily live within the WordPress ecosystem were given (forced into) an occasion to think and analyze their own viability moving forward.
Hammer time
It was hammered home in a way it hadn’t been in a long time that, with a GPL license, anyone can reuse all your code for anything they like. It was hammered home that the WordPress.org repo is a potential chokepoint run by one guy. It was hammered home that Matt can be unpredictable and he is in a position to hurt your business badly if he cares to. Everyone had a rethink.
I count myself among that “rethinking” number even though I’m not yet selling PeakZebra. I was in the process of finishing up a large, complex plugin that I was going to sell, most likely along the “free plus premium” model. Though I think Matt caused a lot of harm he didn’t need to cause by going after WPEngine the way he did, it did at least have the fortunate knock-on side effect of making me rethink PeakZebra’s strategy.
I’ll talk more about that in future pieces, but here I’d like to focus on one of the three main problems de Valk focuses on: the weird and somewhat backward frameworks and overlays of the stack and codebase. As de Valk puts it:
WordPress is often ridiculed by developers in the wider web ecosystem. It’s considered backward, slow and bloated. And the truth is harsh but simple: this is true.
I’m a good person to talk about this, I think, because I only returned to coding four years ago, after a long hiatus. I was a programmer for the first ten years of my career but then got pulled away by more managerial and editorial (though still technical) pursuits. I still had programmer instincts but I was way behind on more or less everything.
Triumphant return?
The point is, I came to WordPress without too many preconceptions (I’d used it for projects a few times in the past, but more as a power user than a developer and prior to the arrival of the block editor).
I’ll admit, I wandered back into WordPress because I thought the opportunity might be converting WordPress sites to static Gatsby sites. So I was just as focused on learning React and Gatsby for a while.
I’ll spare you the details of my earlier programming history, but suffice it to say that React was new territory, as was custom block type development in WordPress with its React components, as was all the action and filter stuff going on it PHP in WordPress.
I managed all this, but largely because I’d been a full-time, very solid programmer in my past life. And I had done a short stint teaching JavaScript back when it was trivially easy compared to the world of JavaScript today. I had pro chops, even if I was diving into the deep end in a lot of ways.
Clarity
You can look at WordPress and see how it arrived at Gutenberg blocks and an editor that runs separately from the rest of the system if you think about the project’s history and motivations. But if you don’t bother to make it a story with a seemingly sensible through-line, if you just look at it from the outside with no preconceptions, it looks like way too many moving parts.
Again, there are reasons why there are so many moving parts, but it’s not really a system you’d come up with if you were designing from scratch today.
— added 2/5/2025
As an aside, though, the bones of modern WordPress aren’t that bad, really, are they? The idea of having a flow that provides hooks where you can tie in your own callback functions is a solid solution to making the core easily extensible without breaking everyone else’s stuff.
Sure, it’s not the terminology that bleeding-edge developers would use to build a similar system, nor would they, in all likelihood, use PHP, but this is almost more about style than substance.
And until quite recently, there would have been–were we writing a fresh, new WordPress–a lot of pressure to write something where computation was pushed out to the edge. At a minimum, there would be more active components running in the client browser. But pushing server functions to the edge would have been the “obvious” thing to do.
Funnily, it feels like pushing server function out of the server ran into precisely the problem you’d expect as soon as you tried to do anything that performed computation using a database. Conceptually, you really can’t divide a database. It has to look, to the higher layers of code, like a unified entity. So for most sites, the server code may as well be running–gasp–on the server. The enthusiasm feels more tempered of late.
—-
At any rate, I think part of the work the WordPress community has before it now is asking itself what WordPress might actually look like if it were designed from scratch. I’m not saying that WordPress should be rewritten from the ground up. Too much real-world, useful capability would be tossed in the process. But imagining WordPress without getting too hung up in current difficulties is part of the process, I think.
Clear eyes might also help us think about the distinctly different directions and needs of enterprise, ecommerce businesses, and blogs. Maybe core is a stripped-down engine with components that extend core for different use cases and levels of complexity. This could be built from the current WordPress, but not without a reimagining of the core architecture.
In any case, a real discussion, as de Valt suggests, is the way to start.
I continue to chew through a lot of time making sure that PeakZebra, as a service, works. That it does what it’s supposed to do.
But I’ve come to realize that one of my major challenges as a founder is training myself not to keep moving the “finished and ready for launch” goalposts. In particular, I have had a tendency to stop at key points, re-envision what it is I’m building, and wind up with a lot more pre-launch work.
Or more simply: whenever I get close to the start line, I find an excuse to push it further away. A mindset problem.
Stopping starting
Thing is, now pretty much all of the necessary code pieces exist and it’s time to just get going with the “having customers” part of the arrangement.
So I’m drawing up a list of every single thing that absolutely must be done prior to launch. I expect this will be subject to a change or two, but I think I’m close enough that I have a far clearer view than I would have been capable of having early on and can make a list that will remain more or less accurate until launch.
I don’t think there’s any sense in sharing the list (and, as I write this, the list doesn’t exactly exist yet–I guess you could say I have a concept of some lists), but I hope to make it in a way that makes reasonable time corrections possible.
By the way, if you’re thinking: “Hey, isn’t this what project management is? How have you managed a big project without some version of this list all along?” Well, fair question, but there have been lists. The problem was that I kept revising the product vision out from under them.
Plowing mode
Also: you’d be surprised how easy it is to keep plowing along, once you’re in plowing mode, without considering whether the thing you’re working on actually needs to be done before launch (or at all). “Plowing mode” is critical but also dangerous.
One additional, related thing I’ve committed to is that I won’t re-write the code base out from under the product once it launches. Revisions of all sorts will of course happen, but no significant do-overs allowed, at least not until the business is up on its feet and humming.
One open question is the one I mentioned a few days ago: to what degree is what I’m doing going to be like a very specialized agency? This is one that I think the market has to decide, but I need to make the case in a convincing way so that it’s a fair test. And so I guess that had better be on the list as well.
Lots of things on the list, but not too many to prevent imagining we’ll be running full speed at the top of the new year.
Nothing has foregrounded the fundamental bargain of open source like the past couple months of WordPress drama. I’m not here to talk about that in particular, but it has really gotten people thinking about what’s legal, what’s ethical, what you can charge for, what you can give away, and how a business will or won’t work within the ecosystem based on how you answer these questions.
Matt Mullenweg recently took over the WordPress.org repository copy of Advanced Custom Fields, for which he received a great deal of criticism. Just a couple of days ago, he included advanced features (the one’s you’d ordinarily have paid for) as part of this free (renamed) version of the plugin.
GPL is a free pass
As nearly as I can tell, this is completely within the letter of the GPL (General Public License, a baseline agreement created by GNU). If you use GPL’d software to make your thing, the anyone else can use your thing for whatever they like.
But this business ecosystem is in some respects built on faulty assumptions, and Matt’s release of “premium features” from Advanced Custom Fields is solid proof of this, barring some significant turn of events in a legal action that hasn’t happened yet (ACF’s parent company WP Engine is suing Matt and others but not over this particular matter).
New models
I am convinced that there needs to be a model for code that is examinable and extendible, but that requires a low-cost license to use (or to use in a business resale context, but I prefer the simpler idea of just charging a small amount for any use). I think a blockchain model of project governance is the way to accomplish this, but that’s a post for another day.
Meanwhile, though, those of us trying to run businesses in the WordPress space are pretty concerned by the idea that their features can be distributed for free on the primary distribution site for the ecosystem at WordPress.org.
SaaS, API or Bust
My take is that you have to offer your business as a SaaS, or a SaaS with a connector plugin, if you want to operate in a way that you can legally protect. If I sell you a service, all you see and use is the service. To date, anyway, what I build the service with is my choice and the code I did it with isn’t necessarily anyone else’s concern.
So if what I’m selling you is essentially access to a WordPress site, you’re using the site, not running the code, and you aren’t necessarily entitled to see the code. I’m probably obligated to make the code available to you if I build it within a GPL context, but this seems effectively unenforceable.
For one thing, anything that I want to keep outside of GPL provisions I can implement as a separate service that’s used via REST calls. The code that processes the REST requests isn’t GPL and you’re not entitled to take it and resell it.
I can even make the source code available to you, but not under a GPL license. I can let you see it but not use it yourself, let you see it but only use it if licensed for a fee, and so on.
Business behind the curtain
In the current environment, what I suspect will happen is that developers will cordon off some portion of what they do behind a REST API and not let you see the inner workings. That’s not really the way I want PeakZebra to do business, but I want there to be a revenue stream that Matt can’t gut at a whim.
The good thing about this sort of workaround, where it is feasible, is that it makes it possible to continue to do business in the WordPress space without undue risk to the business owner. And there are all sorts of great reasons to keep WordPress (and it’s ecosystem) thriving and moving forward.
It occurred to me that I was writing lots of blog posts and posting links to the posts on Bluesky and X. And there were even a couple of good souls clicking through to have a look at the proceedings. But on the blog pages (aka, pages like this) there was no call to action encouraging you to sign up to kept informed of when PeakZebra goes into early access.
In today’s interworlds, it’s probably too much to ask for someone to be curious enough to click on over to the home page, where there’s a dandy sign-up form. So I need to change the template that displays the single blog posts. Done. (Though, looking at it now, the right column needs some adjustment. We’ll get there.)
The confidence game
In general, I’ve been trying to shift my default frame of mind so that I tend to assume that things I’m doing will work as expected. For instance, if you land on a blog page on the site, you’ll give the piece a reasonable chance to hook you. And if there’s a call to action to sign up for updates, you’ll see the wisdom in doing so.
There’s a lot of talk among the startup crowd about launching the product before you’re ready. The supposition is that you don’t actually know yet what’s going to result in legitimate product/market fit. I can’t really argue with that, but I think it leads–at least for me–to a certain laziness about building things to a sufficiently finished point.
I’m learning to trust my instinct on what needs to be finished (and to what degree) before launching. Trusting that I had the right idea also makes it harder to turn away from the project when something shiny appears on the horizon. (Or, for that matter, when some big, not-very-helpful change occurs in one’s business environment. I’m mostly looking at you, Matt.)
Trust the workflow
I think I also need to trust my gut on having a rather different “agency like” workflow behind the core service. I can see a number of issues with trying to make it affordable to make alterations to one’s version of the application. But I also need to trust that I’ve got enough of it figured out that I can find solution for the problems that will inevitably crop up.
The point here is maybe not so much that I need to “become more optimistic” but to recognize that I’m mostly likely to be right in my business decisions and actions. Not infallible, but my best-laid plans actually don’t go awry very often–unless self-sabotage enters the equation.
OK, so what besides adding CTA forms to the blog pages have I missed? Well, a better sample on the front page, but that’s coming. Well, trial accounts, for one thing.
I’ve been thinking that my business model wouldn’t make it affordable to hand out free accounts, but it occurs to me that maybe the trial accounts should be spun up on a multisite instance of the application. While I don’t think it works to use multisite for paying customers (one of the advantages of the current setup is that you have your own instance and thus your entire database is completely separated from any other customer’s database. It’s vastly more secure.
Multisite is secure, I should add. And it’s plenty secure for a short trial period, after which you either get deleted or you upgrade to paid service and we move you to your own site instance.
It occurred to me that I’m so bad at thinking up witty little bits to post on Bluesky that I’d probably do better writing a five-hundred-word piece literally every day and then “skeeting” (as they say on Bluesky, though I have no idea why) the address and topic. I’d have something to say, sort of.
And writing at a steady pace (something I haven’t done in quite a while) means I can do something that’s more my style in terms of building in public. That is, I can get into the weeds on code and WordPress particulars and also talk about some startup decisions more or less as they happen.
The good
I’ve been working away on one version or another of PeakZebra for something on the order of three years now (depending on how you count). This is a terrible way to launch a solo bootstrap business, just in case you were wondering. I think people get problematically cultish about shipping as fast as possible sometimes, but for the most part I do believe it’s a good idea to come up with a business idea that’s relatively small and self contained, at least as far as creating it. Didn’t manage it myself, though.
But the good thing of late is that the vision is considerably clearer and, as I’m putting the pieces together, I’m pleased that some of the pieces that go back fairly far in that three-year period work just fine as I’m integrating them with new pieces. This wasn’t necessarily going to be the case because the framework I was developing for–WordPress Gutenberg blocks–was a moving target the entire time.
It’s funny, when fixing bugs in that older code (because, um, there were a few) to be reminded that, to take one small example, you used to have to enqueue any JS files you were going to use on the client side of your block. Nowadays you can just use a render.js file that you list in your block.json file. All sorts of other minor details have been streamlined in the interim.
And pieces are coming together. I have a test platform that, I guess because I think of it as a blueprint site, I call mrblue. I give my local sites dorky names. The offline version of this PeakZebra.com site is currently totally.local.
The less good
I spend a lot of time wondering whether I’ve gone down the wrong track with the idea of enabling companies to build internal tools on a WordPress platform. That’s in part because I more or less arrived at this goal within an almost entirely WordPress context and I didn’t really dig into all the options that are out there.
I was aware of most or perhaps even all of the no-code application builders that are used by people trying to build no-code startups, but I didn’t really take the time to see what kinds of services were specifically targeting the internal business market.
Setting aside the various things that you can do with customization in Salesforce, there are also quite a few companies that specifically target enterprise internal tools.
Checking these various products out has been kind of depressing, because some of them are very polished and very capable. At least one of them, Budibase, is open source.
So far, though, they are all really most suitable for enterprise use, and I’m more interested in the tiers below that. They are also, accordingly, a lot more expensive. I’m not trying to be the low-cost purveyor, but what I really think is the case is that these other products are really playing in a different product category. I genuinely don’t see PeakZebra tackling the enterprise world anytime soon.
The storm clouds overhead
Meanwhile, Matt Mullenweg seems to be trying his dead-level best to seriously undermine the WordPress economy. I’m not going to make this a forum for my read on the #wpdrama, but what I can say is that I’ve shifted my strategy for going to market with PeakZebra so that I can get closer or farther away from WordPress. More on that another time.
While your first encounter with PeakZebra may catch you a little off guard, especially if you’re coming from a WordPress background, the ideas behind it are actually very straightforward. Which is what makes them powerful, of course.
Halfway with Forms
Particularly in the WordPress world, there’s this notion of an add-on called a “forms package.”
A forms package lets you create forms, needless to say. These forms are presented to users on the front end of your site and when they fill them out and press the submit button…
Actually, that’s where the capabilities of a forms package begin to peter out. In the simplest instance, the data from the form will be plopped into an email in text format and sent to a pre-configured email address (your address, roughly speaking). What happens to the data at that point is your problem.
If all you want to do is toss the name and email into an email mailing service, then that’s likely to work just fine. Most of the larger such services are integrated enough with the dominant forms packages that they can pick up new entries without manual intervention.
There are also forms packages that offer the capability to dump all your form responses into a database table. While that’s a start–and it might even be ok if you only have one form active on your site–but since it literally dumps the data from every form into the same data table, what you typically wind up with is a jumble that you have to sort out by hand. It’s a feature that I don’t really believe anyone with more than one form actually uses.
Enter the Table
Out in the world beyond WordPress, there are several options for ad-hoc applications that start with a table. The original example of this is arguably Google Sheets, even though it’s a spreadsheet, not a database table, strictly speaking. A lot of people use it strictly for columns and rows of data, though. Plus it’s easy and automatic to connect a form (one form, and you can’t control what it looks like) to a table. A more purpose-built version of the same thing is Airtable, which gets an enormous amount of mileage out of good looks (though you can’t change them much) and support for a whole lot of bells and whistles (scripts, automations, widgets that aggregate data and chart it).
The Initial Insight: Known Tables
PeakZebra combines the forms package and better-structured, more “Airtable-like” tables. In a departure from other tools out there, PeakZebra starts with a set of pre-defined tables. This has a couple of advantages. First, it’s faster to get going (it’s also just plain faster) because you don’t have to create fields for obvious things like “city” or “email”.
Second, it makes it easy to tie form fields to the tables. So in PeakZebra, if you add a text field to a form, you can pick which table and which table column you’re connecting to that instance of the text field input. If you want “city”, you just select it over in the right-hand-side column with the various configuration options for that field.
A third, huge differentiator for PeakZebra is that using known tables means we can supply various templates for different kinds of applications and they will–because they are tied to the same underlying tables–be inherently interconnected.
Second Insight: Fields are Blocks
The pages you visit as part of a PeakZebra application are built with the WordPress block editor, using blocks.
Of particular instance, when (and if) you build custom forms as part of your application, each field and each button is a block. So you have enormous control over what your form looks like and how it performs.
Third Insight: It’s Not that It’s WordPress
It runs on WordPress, but what matters is that it runs on a WordPress that provides you with your own SaaS service. So you don’t have to “run” or “administer” WordPress. You just use your customized service. It’s SaaS, but ultimately it belongs to you.
There are plenty of long-time WordPress professionals who will tell you that WordPress is too complex for its own good. I don’t agree, but I’ll readily concede that it’s very confusing to get started with, even if it does offer a lot of power and flexibility.
Thus, while a PeakZebra instance is running on WordPress, the idea is that you’ll be largely unaware of this. You never log into the “admin” side of WordPress (unless you know your way around and want to do something unusual). If you opt to edit the pages of your applications, you’ll be doing so in the WordPress block editor, but in a cleaned-up version that prevents some of the confusions that have made some people less than thrilled about the interface.
In short, even if you’re the admin for your instance of PeakZebra, you don’t have to be the admin on the WordPress instance running behind the scenes. You show up to the website as a user. If you’re the admin, you show up as a user with access to PeakZebra admin functions (adding a new team member, for instance).
Thus
The core ideas that power PeakZebra are pretty simple at the end of the day: tie forms and tables together from the get-go, build the forms from standard block components, and use the strengths of the WordPress platform without forcing people to learn WordPress just to take advantage of the good stuff.
Gutenberg arrived on the WordPress scene five years ago by now, but plugins that implement more-than-basic blocks were relatively slow in coming. Still, five years: so you might think everyone would have it all figured out by now. But no. And plugins that implement more-than-basic blocks were relatively slow in coming.
For one thing, there’s a huge percentage of WordPress users who wish that Gutenberg had never happened. Especially among WordPress professionals who feel this way, they have come to the conclusion that Gutenberg blocks are trying to be something like Elementor or Divi–and that they are failing miserably at it. With Divi, they say, they get pinpoint control over positioning, gradients, and animations.
With blocks you have nothing but the bluntest of tools for positioning, gradient controls (only recently starting to appear) are confusing and inconsistent, where available at all. And just forget about animations–none to be had. That’s the argument.
There’s something to be said for their arguments: blocks arrived to the world in fairly rough shape. Eventually, they got to be pretty good at handling blog pages and, once you got used to some of the quirks, you could put together page designs fairly quickly, provided you weren’t trying to do anything that relied on pixel-perfect control.
Just as we arrived at that point, though, the roll-out of “full-site editing” came along. Now all of a sudden we were asking blocks to carry the weight for lots of things in themes that had previously been handled in PHP templates. Now everything including headers, footers, and sidebars were built with blocks.
Well, FSE was pretty shakey out of the gate, but it’s made steady progress. And there’s been another development as well: blocks have gotten a lot better, a lot more capable, and a lot more interesting. So let’s talk about the best WordPress blocks plugins.
Block variety
There are blocks (and groups of blocks) that I think are presently somewhat ahead of the curve. If you take some time to put them through their paces, you’ll see they show where blocks are headed.
So here’s my short list of the best block plugins that push you to think more broadly about what blocks can do (including things that are well beyond traditional page builders like Divi).
Greenshift Animation and Page Builder Blocks
I’m not a big fan of typical on-page animations, but they are a necessary tool in any web-builder’s toolkit and one thing that block skeptics are always lamenting is the lack of simple animations like fly ins. And it’s true that there are no animations for core blocks or any of the blocks in the more widely adopted block libraries like Kadence (no knock on Kadence, to which we’ll return in a bit).
With Greenshift, you get a bunch of new blocks over to the left of the editor, some of which give you new capabilities, some of which offer spiffier versions of some of the core blocks (from paragraph on up).
For any given Greenshift block, you’ll have some animation options. The text block (a much-fancier-than-paragraph option) gives you a number of options including looping through alternatives for a key word or phrase in your text.
The panel to the right gives you eight animation options for the replaceable section, including a nice one called zoom that sort of superimposes the new word over the old word. Additionally, you have control over the color of the replaceable section separately from the rest of the text–and this includes gradients.
On the advanced tab, you can also animate the entirety of the block, so that all the text can drop down even as the typewriter animation, to pick another option, types in the first word of the replaceable part. The effect here is way too busy, but the point is that you have a lot of options.
And the larger point is that the Greenshift group of blocks is a lot more of a Divi replacement than most of the Divi loyalists would care to admit.
Mindspun Payments
Mindspun is a startup that clearly gets the value of a block-based approach and they work in an area that makes enormous sense to tackle with blocks: the payment space. I say “payments,” but their blocks do a lot more than that, handling pretty much the whole stack of things you need to sell, in particular, digital products (including licensing and managing downloads).
If you think about it, a checkout page is a group of elements that break down readily into separate chunks (that is, blocks)–and also a place where the blocks need their individual functionality tied together into an overall package.
I like what I see enough that you’ll be seeing a Mindspun Payments installation right here on PeakZebra.com before long.
Block Visibility
This plugin doesn’t add blocks to your site, so you could argue on a technicality that it’s actually not one of the best WordPress blocks plugins. But all the same, it’s a good plugin for blocks–one that takes advantage of the architecture of blocks to add a “Visibility” panel to every block on your site. So if you only want something visible during, say, business hours, you just set it so that this is the only time this block (whatever it is) is visible. And you can place this setting on a group block to take care of whole section of a page.
I wanted to mention this plugin not just because it’s handy, but also because it’s an example of a block that behaves different ways in different contexts. I suspect we’ll see more and more of these.
Content Control
Here’s another plugin that adds a panel to existing blocks on the site. It gives you the sort of controls you’d want for a membership site, and gives them to you on a fairly fine-grained basis.
You can use it to drop blocks from a page (visually) on mobile devices, for one thing. But you can also restrict views based on user role, as I’ve done here. Mere subscribers will not see the paragraph block in my example page above.
It’s the kind of thing that’s perfect for a call to action that you want non-subscribers to see, but that people who’ve already subscribed will just see as a nuisance.
Custom Blocks Creator — LazyBlocks: Make your own best blocks
I’ve liked this tool since it first emerged. It gives you an interface to create blocks without having to know the full-blown block creation process. Instead, you can build blocks exclusively using some drag and drop controls and the PHP you already know how to code with. And you can do full-speed, heavyweight blocks with this.
The cool trick to it is that it hides all the JavaScript and React that would normally be associated with creating a block. Rather than code the controls that appear in the inspector panel, you pick them and configure them to name the things you wind up storing from them. To handle the data that the user adds to the block, you write code in PHP (or present it in template format). It’s pretty darned seamless.
One point about it that might make a difference in some instances: the PHP rendering magic is accomplished by creating dynamically rendered blocks, as opposed to blocks that are pre-rendered and stored as straight-up HTML. The traditional pre-rendered approach is inherently more performant, but that’s only going to matter in certain kinds of instances (high overall volume to the site, or some kind of process that makes rendering slow but could be handled without dynamic rendering).
For the most part, though, dynamic rendering just doesn’t inflict much of a performance price–not the sort of thing you particularly notice on a typical site and not the sort of thing that’s going to send your Lighthouse scores into the dumpster.
Code Block Pro
I discovered this very recently and I freakin’ love it. It displays your code samples as if you were viewing them with syntax highlighting in VSCode. Indeed, it uses the VSCode engine. It handles just about any programming language you can think of and offers a ridiculous number of VSCode themes for different colorways.
The point here is that it’s a block that brings an enormous bunch of capability to a specialized kind of display and means that no one else has to do all the heavy lifting to get it done for themselves–exactly what blocks are about.
Kadence Blocks
If you’re following the world of blocks, you may well already be familiar with Kadence Blocks, because there’s a fairly large group of block-based site developers who have chosen Kadence as their go-to set of blocks.
The Kadence package is pretty typical of a class of plugins out there that provide a whole set of blocks that more or less replace (or at least significantly augment) the WordPress core blocks.
I mention Kadence because it was out there early in providing lots of the fine-detail controls that were missing in core blocks. In the Kadence text block, you can alter settings not just for typeface and font weight, but also things like character spacing. Core blocks are, to some extent, catching up, but progress there has been uneven. And I don’t know whether the core blocks, with their emphasis on keeping things simple, will ever have all the controls for drop shadows and so on that Divi users are accustomed to. But the point is, block groups like Kadence (and others such as Greenshift) will fairly soon have all those bases covered.
Enter the Zebra
Blocks can do other, perhaps less expected things. In the context of this article, at least, I think they are the best WordPress blocks plugins for this very reason. And I’ve tried to do my part to push things along: the blocks I’m building with PeakZebra, for example, work with tables in the site’s SQL database, for example. And they handle display using React on the front end, so that it’s possible to have a table that interactively lists a table of people, for instance. Personally, I like the idea of bundling up the blocks and their presentation in extended themes or blueprints.
On the editor side of things, you can choose which columns to show, how many rows to show in the box, and what should happen when a row is selected.
Meanwhile, on the front end, the end user can shift the column order, sort by column, page through data without a page refresh, and so on. Like a modern web application, you might say…
The point is not that it’s got to be PeakZebra supplying you with blocks like these, but rather that these kinds of blocks are on the way. Maybe they’ll be custom to your particular needs or maybe they’ll be utility functions with broad application, but they’ll be doing things above and beyond text on the page.
