Author: Robert

  • Slots to Slotfill, Callbacks to Call

    So, one key challenge to tackle is managing changes to individual PeakZebra deployments without creating variants that can’t be merged back together.

    My initial thought was the WordPress slotfill capability, probably because I was aware of it but didn’t know all that much about it. I did a little poking around, enough to realize that it’s only relevant in React contexts. In other words, could well be relevant to situations where blocks are going to be rendered, but otherwise not the droids we’re looking for.

    Single file of truth

    So we’ll get back to slotfill at some later date when other more pressing versions of the broader problem have been worked out.

    So, an initial thought is that, if at all possible, per-client changes to PeakZebra’s base deployment should be stored in separate files, perhaps with there being one agreed-upon file that is always included and executed on every deployment. Think of it as a kind of functions.php file, but for PeakZebra plugins, not themes.

    Given the SaaS nature of PeakZebra, one could even contemplate just putting client-specific stuff in the actual functions.php file, but that seems like a potential long-term creator of problems.

    So the current approach is a file called client.php that will primarily register and hold the code for a bunch of PeakZebra specific callbacks.

    But which callbacks?

    So far, I’ve used the facility that’s build into WordPress core for this, but I suspect I really need the callback functions to have an option to completely replace a function within PeakZebra. This of course creates its own problems (how does the replacement function keep synched with code it’s taken over but that has changed in the original version since it was carved away?

    One potentially nice benefit of routing everything through client.php is that, for the foreseeable future, each client’s version can be stored as a unique branch in a single git archive. That should be acceptably performant (and it’s performance during dev, so it’s not about top performance in any case) up through several thousand clients, at which point the client.php files may need to live in their own database.

    So each client’s series of modifications, at least in actual code (as opposed to configuration and content changes) will be stored throughout its revision history and always retrievable by branch.

    This leaves, for another day, a whole lot of questions about which hooks are needed, and so on. We’ll get there.

  • The Launch List

    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.

  • The WordPress Version Control Divide

    I was checking out a podcast video by Brian Coords when I hit upon an exchange that both outlined the difference between a developer/workflow-based approach and a more traditional WordPress approach to managing changes on websites.

    What I love about this conversation is that both interlocutors are obviously not only smart, but smart about WordPress. I’m familiar with Brian from Bluesky and X, but hadn’t run across Mark Szymanski, a WordPress content creator. Mark enters the conversation hoping to get insight from Brian into the whole version control thing.

    Inside, outside, upside down

    There’s a moment early on where Brian lays out an important distinction between people more accustomed to doing everything inside a WordPress installation’s logged-in environment and those more accustomed to writing code outside of the running system and then deploying it.

    “This is the biggest core concept that people are struggling with with WordPress and the block editor. … If you came from page builders where you do everything … inside of WordPress, you’re not writing code, you’re not in the code base,” Brian says.

    “Versus other people who come from a heavier code background–they want to do all that stuff in code and then put that on the site.”

    One thing that fascinates me watching their discussion is that they spend a while in the early going almost but not quite talking past each other. It’s a clear indication of the kind of difference between “in-frame” designers and “out-of-frame” developers. On the one hand, Coords is mainly talking about code and configuration files that can be checked in to a git repository. Typically this would only apply to the files you’d create and maintain to build a plugin (perhaps one that creates a custom block) or a theme.

    Syzmanski, on the other hand, is talking about tracking all the sorts of changes a person might make by adding a plugin to a site, or developing a page using a page builder like Elementor.

    Database difficulties

    And this latter category of stuff, which in the podcast they agree is “content,” broadly construed, really doesn’t fit in any obvious way into the world of Github repositories and code deployment.

    New to me was an approach used by high-end enterprise WordPress sites: “code goes up; content comes down.” Roughly speaking, this means you can’t write things that will be stored in the database “up” from a developer’s local copy of the site to the production site. That “content” can be copied down, but not up.

    What’s allowed to go “up” is code, by way of being committed to a repository and then deployed to production from there.

    No self control

    Alas, it became clear that they weren’t privy to some deep magic way to version control the “content” part. This doesn’t exactly surprise me–I think it’s pretty much where the vast majority of us have landed–but it became clear that the discussion was mostly about how people approach managing specific directories of code in WordPress. If you’re developing a custom plugin, for instance, you’d have directories for source PHP and JavaScript files (as well as things like .JSON files) that you can send to a repo just like any other programming project.

    Meanwhile, though, I need a way to track this stuff and my own take on this is that what’s needed are version-controlled “make” files. Each file is a set of code instructions to move from one version to the next (across the whole WordPress site).

    I’m glossing over a lot of detail, but my thought is that the way to keep things honest is to have a staging site that you can only update by submitting a make file (or a batch file). Possibly this can all be done via WP-CLI. I’ll have to do a little poking around.

  • Another Side of WordPress SaaS

    One thing about the strategy where you hedge your WordPress bets by offering your wares as a SaaS built on WordPress is that it opens up the question of what’s in your SaaS.

    Once you’ve created a setup where your SaaS customers are interacting with your WordPress server, a potential next step is to incorporate some third-party package into your build and offer access to that as part of your service.

    Anticipated?

    Some of the more complex plugins out there absolutely anticipate this sort of use and have options that let you license the plugin accordingly. Others, less so, and it’s also worth considering that nothing says you can’t take free plugins and offer them wrapped up in your service in the same way.

    It’s easy to see how you might end up with a scenario where you’re wrapping up a paid plugin with a lifetime, unlimited license that doesn’t cost very much and then reselling it heavily. It’s the kind of thing that makes you wonder whether you’re taking advantage, but then again, the unlimited licensing is largely targeting agencies who are reselling the product at a markup, just not necessarily in SaaS packaging.

    By and large, I think it’s legit (though I’m open to counterarguments). If there’s an unlimited license on offer, then SaaS resale seems entirely above-board, from a licensing perspective. And, for better or worse, there’s the fact that GPL licensing pretty clearly requires that you let people take your code and resell it if they want, just as long as they credit you and retain the same licensing.

    The admin side

    One potential problem with a SaaS setup is that your end users may well need at least some access to WordPress admin functions. But you don’t really want them having to learn their way around the back end, probably don’t want them poking around in there in any case, but on the other hand you probably don’t want to have to write a front-end version of the admin functions.

    For this, though, there are a couple of plugins that expose some or all of the back-end interface to front-end users.

    The one that I’m using for this particular need (for the time being, at least) is WPFrontend Admin. It enables you to create front-end pages like this one, where the guts of the user admin interface are nicely nestled inside a front-end page:

    screen shot of a WordPress user admin table.

    It’s a clunky design, just like it is on the back end, but you can pretty it up a bit by overriding various CSS settings. I haven’t really dug into that yet, but what this gives PeakZebra is a way to allow clients with the right access privileges to manage the user’s they’re allowing on their instance of the PeakZebra service.

    PeakZebra users

    As it happens, I’ve also written a spinoff of the PeakZebra form blocks that specifically map to WordPress user account fields (and meta) and that are specifically for use on the front end. They’re implemented using the Interactivity API which means they will at some point confer special, magical powers.

    But implementing a full copy of the user admin interface at this point in PeakZebra’s development seems like a pretty significant detour, given that I can just surface the user admin functionality on the front end using the plugin.

    The thing about the Frontend Admin plugin, though, is that it’s expressly built for the scenario where you resell a complex plugin. Let’s say you take the Groundhogg CRM. It basically lives on the admin side of the site where you install it. But you can make all those pages magically available on the front end with the Frontend Admin.

    And this trick works with all sorts of plugins. Check out their list of common applications used this way.

    I don’t think this is the future of WordPress, exactly. But we’re going to see more cases where people are using this sort of setup to keep their own modifications hidden on the server side of things. Whether this is a good thing is debatable, but I think overall it’s a good thing to have a business ecology around the core open-source WordPress project, and the status quo of how business exists in the WordPress world is clearly being seriously re-evaluated right now.

  • Common Codebase Versus Custom Deployments

    These days I’m spending a lot of my time making sure the PeakZebra product works.

    But it’s clear to me that quite possibly the biggest challenge I have before me is dealing with the dead certainty that there will be lots of customizations made to client instance of PeakZebra. In a way, that’s PeakZebra’s secret weapon: you get exactly what you need for your app.

    I know how to manage this is a general, not all that optimized way, but I’ve started thinking about how to scale this so that I can handle thousands of clients with lots of different deployments.

    Deployment?

    To start with, even what counts as a deployment needs tighter definition. There’s a lot of code in PeakZebra, and that code is tracked using git and GitHub. There needs to be a good way to deal with having different versions of the actual code across different deployments, because that’s definitely going to happen. It’s going to happen lots, I presume. So it isn’t as simple as having

    Second, a production WordPress site is a big amalgamation of things that profoundly impact the site’s look and behavior, but that aren’t necessarily code that would be checked into a repo somewhere. You can add custom post types using a plugin, for example, and it’s genuinely important, should you need to recreate the site, that those custom types be checked in.

    Also, many changes that are made to a WordPress-based app result not in changes to code, but to changes in the database. We don’t really want to check in a new copy of the database every time anything at all gets tweaked, do we?

    Tracking the combinatorial

    But what’s the best way to track all this amalgamated stuff?

    One could, in theory, just keep a full backup of each site (which is, not surprisingly, what most developers and agencies do). That doesn’t really answer the needs of the “backside” of all these deployments.

    Whatever the system is, it needs to be quick and efficient for a developer to make changes to each system. Yes, there’s a more or less common codebase. But in order to make changes, the developer needs to know what other customizations have been made to this deployment and how to avoid inadvertently breaking prior modifications.

    And there’s another twist. Some of the changes will make sense to propagate back to the “original” code base. But how will the developer know they aren’t going to break other sites with other modifications when the next update to the original code rolls out to all the other deployments.

    Non-computable?

    There’s almost certainly a “computer science” way to prove this is actually an unsolvable problem. But before we panic, let’s note that most changes, most of the time, won’t matter to other sites and aren’t likely to break much of anything else. Not in the WordPress world, where things are always running with the assumption that each site is cobbled together with a combination of parts in addition to the core code.

    Basically all I’m aiming to do in this particular blog entry is lay out the problem set, but let me say a few things about how I’m viewing a solution.

    First, I think there probably needs to be a scrubbed-data version of each deployment stored on local servers in a “ready to use” status. Imagine hundreds of local deployments, each with a copy of the code used in the relevant PeakZebra plugins.

    Given that WordPress stores revision histories for posts, this capability with regular backups, plus git repo storage for all the actual code, could potentially solve the problem of being able to track thousands of revisions across thousands of sites.

    What it doesn’t do is help the developer not shoot themselves in the foot while updating a particular site. More about this in future posts.

  • The Limits of Open Source Software

    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.

    At the same time, there’s been something of an understanding in the WordPress world that you can charge for plugins and themes if you want to, and there’s a genuinely large business ecosystem built around this.

    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.

  • Adding Logic Cleanly

    With the WordPress block editor, you get a reasonably good editor for managing the pieces that make up a typical web page. And that can include things like forms and interactive charts and so on.

    For that reason, PeakZebra uses the block editor as the interface for any clients that want to build or customize their own pages. They are otherwise shielded from the potential confusions of the WordPress back end.

    But while the block editor is good for making a page that looks like part of an application, you have to ask the question: what happens when something is supposed to happen.

    Enter logic

    For “normal” form processing, PeakZebra justs handles putting any updated values from forms on the page into their appropriate database records. For use cases where you’re just tracking data (what’s this client’s mailing address?) that’s surprisingly powerful all by itself. If you use address fields in a form that gathers client information, for example, simply submitting that form ensures that the data winds up stored in the right table.

    But what’s needed beyond that is a (relatively) easy way to make more complex interactions happen. I think what you need is some kind of logic block that’s configurable in the editor–you give it a set of instructions through some kind of GUI–and presumably not visible (though present and ready to do its work) in the front end.

    Alternatively, you could simply make it possible to attach actions or code to each element of a form or other block and tie them to specific actions (onclick, for example), in pretty much the same matter that HTML lets you attach JavaScript to element events.

    The lotsa-pulldowns approach

    While Bubble and other no-code platforms use a sort of “assemble instructions by clicking options” approach to attaching procedures to elements, I’m resistant to this, even with a client base that doesn’t really want to code.

    That’s because it quickly becomes nearly impossible to keep track of what’s going on (or what’s going wrong) because you have to go back through all the options you selected in that visual interface, plus you can’t get any coherent overview of your whole application’s logic flow. (Actually, maybe one or another of the no-code options handles this well–I’d love to get a heads up on that.)

    So it’s tempting just to make it easy to insert plain old code snippets into a logic block that essentially just exists as a container to put that code in. This, of course, means people have to code at least a little in order to take advantage of this.

    One ecosystem divided by two languages

    In the WordPress world, this approach gets more complex right out of the gate because, of course, WordPress uses two separate languages: PHP on the server and JavaScript on the client side. So should the logic block handle one or the other, or both. And does this increase the complexity sufficiently that this just can’t be termed “low code” anymore.

    I’m tempted by the idea of creating a highly-simplified language for describing what should be done, like:

    see if zipcode begins with “19”

    if yes, set timezone to “EST”

    And then this would parse back into _either_ JavaScript or PHP, as appropriate. Sounds so easy, right? What’s a programming language but a huge nested if statement, amirite?

    Let’s be real, or else let’s use AI. It’s magic.

    Sure. However. Given that this is almost certainly way harder than it sounds and would be a constant source of annoyance while the kinks were ironed out, I then begin to wonder whether AI is the answer. It’s the answer for everything else, after all.

    And this actually does seem plausible, given how good copilot style programming assistance AI has gotten. You’d just need to train the AI on the specific codebase, something that Cursor does already, though I haven’t tried it yet to see if it actually “gets” a WordPress code base.

    But I don’t think, for the moment at least, that AI is really the answer. And that’s because experienced developers bring some important horse sense into the game.

    Horse sense to the rescue

    It’s pretty easy to design a system that does something that is error prone and non-scalable from the get-go. If you talk to a developer who really understands the code base and what you might be trying to do with it, they can help you see if you’re really tackling the problem in the right way, with the right approach.

    In other words: maybe you could get the count of the number of tasks associated with a project by counting the tasks associated with that project in the task table, but maybe it’s better to keep a running total that the system updates whenever tasks are added or subtracted from the project.

    You want someone at least looking at this from a perspective that has the whole picture in view.

    For the foreseeable future, this is how PeakZebra handles these things: by request. Your request to do X or Y is handled by a real, human programmer who is familiar with the PeakZebra code base as well as the WordPress platform (from a technical perspective).

  • Adjustments in Thinking

    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.

  • Daily Dose?

    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.

  • PeakZebra’s central architectural ideas

    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.