Category: Business

  • Airtable things

    Since the stuff I’m building these days has similarities to some of the things Airtable does, I figured why not build a version of the request queue I’ve built with PeakZebra, only with Airtable.

    TLDR: Throw in all the AI you want, once you’re past just storing everything in a single sheet, it’s pretty easy to make a false step (or use the AI to try and do too much) and you wind up with something that just doesn’t work. And it’s possible that it won’t be obvious to you that it’s not working like you think.

    Airtable is pretty cool and there’s no question that it’s got way more polish than PeakZebra does just now, but then again, there are ways in which it’s considerably trickier to build things with Airtable if you’re coming in cold.

    Magic AI bullshit

    These days, it almost goes without saying, Airtable has some magic AI bullshit built in. The promise is that you describe the app you want and it builds it.

    Honest to god, I didn’t try to trick it into screwing things up. I tried to come up with a concise description of what I wanted my request queue to do. I’m afraid I didn’t preserve the actual prompt I gave it, but I can tell you that it created tables that appeared to do the right things, but the relationships between them weren’t at all correct.

    So the AI stuff was a bit of a crock, but that’s not really what I was interested in getting at in any case. And if you just wade in and do it yourself, there are all sorts of things Airtable does that are very powerful.

    Easy and powerful things

    It’s very easy, for example, to connect a field in one table to records in another table. For instance, if you have a table where you store all the requests that are coming into your request system, it’s easy to tell it that the client field should come from the clients stored in a client table.

    And there are some nice touches. When you click on the client you’ve chosen in one of the request records, it pops up a view of all the data in that client’s client record. Handy.

    So the app let’s you establish clients and let’s you create a form for adding requests that are associated with your client identity.

    Twist once for death

    I wanted an extra twist, though. I wanted to be able to let a client create a bunch of associated requests–all the tasks needed to carry out a given project–but not necessarily put all of those tasks into the request queue.

    So I wanted a project table to store the name of various projects, plus a tasks table to hold all the tasks associated with all the projects of all the clients.

    This is easy enough. It’s also straightforward to add a field that toggles to tell you whether a given task is currently in the request queue.

    Doing this, though, means that you don’t want to store requests in a request table, but that instead you want the request queue to be a view of the tasks table that filters on tasks that are flagged as being in the queue. You can also add a further filter or grouping to show the queued items by project and/or by client.

    Wait, one more twist

    Ah, but another twist. Some things are projects with a bunch of different steps, each one handled as a separate task. But other things are one-off things that need to be done and that really aren’t part of a task. Say you’ve got a website and you want to request a change in some content on that website. That’s not a project.

    You could create a project for “non-project” tasks, but what’s conceptually cleaner is to have things in the queue either be tasks from projects or be standalone tasks. There’s no obvious way to have a field be populated by data from either of two tables.

    Now, let’s be clear. I don’t have any doubt whatsoever that there’s a way to do this. There’s almost certainly several different ways to approach it. But if you’re trying to avoid learning lots of technical minutia about the Airtable environment, you’ll hit a wall with something like this.

    Sometimes a little code is the magic

    The PeakZebra approach doesn’t preclude figuring out how to do the trickier stuff yourself, but as part of the basic arrangement you also have the option of just, well, using the PeakZebra request queue (on PeakZebra, not Airtable) and just asking us to do it for you.

    But my real point here, I think, is that services like Airtable and Notion and others are focused on making everything work for everybody without requiring any code. And this can sometimes completely obscure the ease with which the same thing could be accomplished in a “low-code” approach with just a couple of lines of code.

    And oh by the way: I’m not as against AI for coding (and similar code-like tasks) as it might sound like in this post. I’ve been doing more and more AI assisted programming of late, and there are definitely things about it that make me loads more productive.

  • A Modest Licensing Proposal

    Hey OSS folk: we need to start thinking outside the conventional GPL licensing box. We need a rational ecosystem for paid plugins and themes (in WordPress) and analogous capabilities on other OSS platforms. I think we can create a much better arrangement for all involved.

    I envision a licensing system that allows participation in an overarching governance system. If you want to take part in a project that uses this system and use its associated .org repositories and so on, you’d get a license for any internet-facing deployment. You’d pay a small licensing fee, let’s say five bucks a year, calibrated downward as needed to take differences in international buying power into account. Five bucks gets you a vote. For some number of sites, let’s say two dozen, a single five buck payment would get it done, but for big players, measured by sensible metrics but I’m not sure which, more cash would be involved. And bigger players would have more (but not infinitely more) votes.

    It’s a board!

    The main task for voters would be selecting a three or five-person board, but for really large issues (classic editor or blocks, to take an example from the past), direct votes might be called.

    In a greenfield new project, I’d propose a mechanism where the project creator got a big block of votes, such that they could be benevolent dictator for a while (I think there’s value in this, early on—clarity of vision and so on), but as popularity of the project grew and more people acquired licenses, the control would naturally and gradually shift over to the community as a whole.

    Who runs the thing that run the things?

    Who would run this? I imagine a few pillars of the OSS world forming some legal entity that maintained the license sales and voting procedures. It would be possible, maybe even preferable, to run this on a purpose-built blockchain, but it’s hardly a requirement, as the community would just need to trust whoever was running it.

    Now then, what about the money? All the things you might expect the money could be used for would be what the money was indeed used for, at the discretion of the elected board. And we’re talking about a substantial amount of money, the kind of money that drives early marketing campaigns, but clearly also full-on development in the form of sponsorship for core developers and, well, other things like a project’s training videos on YouTube…all the things.

    Not GPL

    To make it work, we’d need to step away from GPL licensing. That sounds severe and even ill-advised, but just because something isn’t running under a GPL or MIT license doesn’t in the least mean it can’t be open source.

    With a non-GPL license, we could have the benefits of open source, but create ways for companies writing plugins and the like genuinely to keep control over how their code was used. The code could remain open, or mostly open, but no one would be in a position to simply take code and sell it as their own (something GPL expressly allows). If the takeover of ACF as SCF didn’t feel right to you, this is how to fix the rules that make it possible.

    If we went this route, selling licenses for use of the governance services of new OSS projects, we could deal with problems such as though currently creating havoc in the WordPress community in a straight-up fashion. Under this kind of arrangement, Matt Mullenweg would have migrated out of a BDFL role years ago. We can’t undo the WordPress GPL license (if we even wanted to), but we could avoid wasting our time wringing our hands and making squeally noises. That’s right: squeally noises.

  • A Twin-Star Site Model

    I don’t love the name, but I think the creator economy is a real-enough thing. There are at least a couple million creators on the web, I read somewhere, who make a living at it.

    My impression is that they either go with something like Patreon or Substack as a way to platform themselves, or use Gumroad to sell things, or exist more or less entirely on YouTube, raking in the ad money. Maybe you can run your whole shop on Patreon (they’re introducing a community capability, founder Jack Conte even has a whole theory about how this makes sense and indeed, he does make some sense).

    Creators and cobblers

    It seems like most creators cobble both their online presence, the tools they use to manage that presence, and the back-end tools for accounting and stuff out of various pieces.

    I suspect a lot of time gets wasted in the cobbling and the learning involved with these tools. Fact of the matter is, for most creators, they typical tools are just way to feature rich and, as a result, complex.

    I’m not a creator in the sense that I’m talking about in this post, but I have done some of my own cobbling, enough to notice that, for instance, Quickbooks is just way, way, way more capability than I need, because all I need is to send out and track a few client invoices. And at nearly $40 a month for Quickbooks, I’m paying way too much for the privilege of letting them email my invoice forms.

    So I’m dropping Quickbooks in the new year and the general plan is to eat my own dog food. (I hate that expression, I think because I find life analogies that use food inherently coarse. But I can’t think of a better alternative–send help.) I’ll use PeakZebra to knock out a dead-simple invoicing system.

    PeakZebra(s)

    Whatever I pull together using PeakZebra, my plan is to evolve PeakZebra to support a “twin site” scenario where one site (PeakZebra.com) is the public facing site and another site (PeakZebra.something_else, presumably) will handle the back end things.

    This means that some elements will reside on the front-facing site, things like newsletter signup forms, to pick the simplest example. But when that signup form is submitted, it will be sent via an API call to the PeakZebra code on the backend server. The data from the form will be stored in the backend server’s SQL database, and when it comes time for me to do something with the data stored there, I’ll log in and use apps on the backend, while the front end site hums merrily along.

    Enhanced security

    With the right setup, this is a more secure approach to managing things like subscriber data, because you can put a lot of controls in place around who access that site than you can on a site that you want anyone and everyone to be able to at least see. And while WordPress is secure when properly configured, it’s safer still if the data isn’t even on the visible site.

    We’ll see how this goes–it’s not an immediate priority to have a “twinned” site arrangement, but I can still work on the sorts of simple tools I want, running them for now on PeakZebra.com but eventually migrating the backend stuff to a backend WordPress install.

    Is a twin site actually more secure? I think so, but I also think the crux of the question comes down to how secure you think the API calls that the front will make to the back will be. For my money, those can be locked down pretty darned tightly.

    You wind up with an arrangement that most attackers won’t have encountered before, with API calls being made from server to server. The attacker will not ordinarily have any way to see the API request data, nor will they be able to see the second server on the net unless they find themselves within a fairly narrow IP address range.

  • Imagining a WordPress Greenfield

    Just suppose, just for a moment, that you and I were tasked with creating something every bit as wonderful as the wonderful parts of WordPress, but starting with a (mostly) blank slate.

    It’s the plugins

    Well, one thing we have to get out of the way right away is what to do about the huge number of useful plugins that are the particular strength of the WordPress platform. Do we want to walk away from the ecommerce plugins, the learning management kits, the membership tools?

    If we want our cake and the eating of it, we’ll have to reckon with the immutable fact that all of that stuff is written in PHP and it all runs on the server. There are no lambda plugins. There are no client-side plugins.

    And it’s PHP. Some folks argue that PHP is antiquated, but I think that’s about fashion more than sense. It’s a fairly sophisticated language, performant, all that.

    All JavaScript?

    But as long as we’re declaring a fresh start, you’ve got to reckon with the hard truth that PHP doesn’t run on clients. Essentially, JavaScript is the only choice in that regard. And if you’re running JavaScript on the client, it makes life a lot easier to be running the same language up on the server.

    If we change gears and use Node.js on the server, then the challenge is finding some way to continue using existing plugins.

    I’ve turned this over and over in my mind. On the one hand, it seems pretty likely that a WordPress-specific translator could be built to turn plugins in Node.js plugins. If we do that, though, then we have to support all the action and filter hooks.

    So, on the other hand, maybe what we want is to make it easy for plugin providers to rewrite their code bases anew. Assuming an approach that was generally similar to WordPress’s approach, developers would have a pretty good sense of how they should approach various tasks.

    For example, you’d probably want get_current_user() to be getCurrentUser() and you’d probably want it to return a user ID. And you’d want to have roles and the roles would be collections of capabilities.

    Post much?

    That’s easy enough (maybe), but do we really want to commit to preserving the concept of everything being a post? We’d have to give that one some thought, but maybe the easiest way forward is to stick with posts and pages and custom posts and such.

    There’s a lot of complexity in core, though, the inevitable result of organic growth over twenty years, and maybe we just carefully sort through and discard a lot of the baggage that still works but probably was never such a great idea. And maybe we tack on a new concept or two, like having a React-like routing system be the default.

    But what we want is for WooCommerce defectors to have a straightforward sense of how to write a new and significantly more straightforward ecommerce solution. NewCommerce?

    Astro adoption?

    There’s another question to consider: given the complexity of building this sort of system, possibly the best way forward is to start with an existing system and then add on whatever stuff is needed to support critical plugin rewrites.

    This is the line of thought that has landed me at the front door of the Astro community. If you’re unfamiliar with Astro, it does content sites, like our friend WordPress. And it’s server centric, like WordPress. But it’s also vastly newer and thus not yet covered in all those rustic barnacles.

    It appears to have themes. It doesn’t, as far as I can tell, have plugins in the sense one has them in WordPress, but it seems at least conceivable that an interface to a plugin system could be created. It doesn’t have an in-built editor, but again, that seems like something that could be whipped up. Or, in a funny little twist, I feel pretty darned confident that the WordPress block editor could be pressed into service.

    So I’m going to explore Astro. Not because I’m so convinced that the current troubles in the WordPress world are going to lead to WordPress falling apart, but because I think we all need to think about hedging our bets. And, frankly, because there may be better options out there in the blog-and-content-creation universe.

    So, more to come on this. One clear takeaway, though, is that WordPress has built up an enormous and enormously useful ecosystem and feature set over the years. Leaving would be painful.

  • World’s Simplest CRM

    Here’s a use case for PeakZebra that I think makes all the sense in the world.

    We begin with the thought that most of us actually don’t need lead scoring automation.

    Just the facts

    You do need to be able to store information about your prospects. And if they they become customers, you need to make a note of this, either within the same database or by transferring them to some other system. And you need to track their payments and so on.

    For a lot of companies, there’s not actually all that much distance between prospect and customer. For instance, someone contacts you to ask for details on the professional service you offer. You talk with them, gather some info. Maybe you make them a written proposal. They accept the proposal or they don’t, but even if they don’t they aren’t, should some future opportunity lead to a new proposal, exactly a run-of-the-mill prospect anymore.

    Whether a potential customer or an actual customer, you need their contact information and you need to keep a record of your interactions with them. If they send you an email with a pre-sales question, you want to keep a copy. If you give them a Zoom tour of the product, you want to have a record of when and what they thought about it.

    You need to be able to track any deliverables you’ve promised and you need to be able to set reminders for future follow up.

    If you’re really on your game, you can also be learning about them as they interact with your web site and you can build up a segmentation model for your customers (and your prospects, which is arguably almost more important). That work happens on your customer-facing websites, of course, but PeakZebra supplies some great tools for that.

    Not Rocket Science

    The key point here, though, is that none of this is actually complicated. Salesforce will do the job, but you’re paying for the whole lot more that it can also do. Like lead scoring. Even at the small business entry level version, this is $25 per user per month. The next step up is $100 per user per month.

    The PeakZebra approach is dead simple. There’s a “Person” grid that shows contacts. If you want, you can easily have different grids for prospects and clients. If you click “Add a New Person”, you get a form for that.

    Out of the box, you can associate each contact with a particular internal team member. You can tag each person with whatever tags you like (you create them), and you can make a note of each interaction you have with them over time.

    Simple, then customized

    And that’s it. Unless you need something else. In some cases, you can simply add on things you want, if that’s your preference. But you can also queue a request for the change. We generally deliver them within two business days and at a very low cost compared to hiring a conventional developer to jump in cold.

    You can learn more about the pricing model for this sort of change by signing up for our occasional email updates.

  • Naming the Business Model

    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.

  • Is the WordPress Plugin Economy Played Out?

    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.

  • A Real-World Example of Avoiding Unneeded Prelaunch Dev

    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?”

  • What WordPress Should Be

    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.

  • 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.