Category: Business

  • Why Substack Costs You More Than You Think (And How to Keep That Money)

    If you’re a creator building an audience, platforms like Substack and Patreon may feel like the perfect solution. Yes, there are Substack costs, but they make the process dead simple. Yes, Patreon (and most of the other similar platforms) have percentage-of-revenue costs, but they make publishing simple and help you collect payments without much hassle.

    It’s funny with Substack in particular, given that sending newsletters is essentially a commodity service. You can send a weekly newsletter to a thousand subscribers for chicken scratch, so convenience comes at a more-or-less ridiculous price. And if your creative enterprise grows to include other kinds of products–online courses, perhaps–you won’t even enjoy simplicity anymore, not if you try to make the various platforms look like one coherent brand.

    The Platform Tax Problem

    Substack charges 10% on everything you earn. Patreon takes 8%. And that’s before you factor in payment processing fees (typically 3%).

    Here’s what that really means for your income:

    • $1,000/month on Substack → you lose $100.
    • $5,000/month on Substack → you lose $500.
    • Over a year? That’s $6,000 gone—money that could fund your next project, upgrade your tools, or give you breathing room to create more freely.
    • Or think about it this way: if you throw that kind of money into your retirement account instead of throwing it at your platform for thirty years straight, you can literally retire on the savings.

    And It’s Not Just About Substack Costs

    When you build your audience on someone else’s platform, you’re renting space. That means:

    • They set the rules.
    • They can change the fees at any time.
    • They control the algorithm that decides who sees your content.

    To be honest, I think it’s fine, even necessary, to have a presence on platforms you don’t control. It’s even fine to get the lion’s share of your revenue from one of them.

    But you need to have a “center” to your universe that actually belongs to you. Practically speaking, that means you need a website.

    If you don’t own your platform, you don’t own your business.

    The Alternative: Own Your Platform

    Owning your own site means:

    • No platform tax on any capability you can add directly to your website.
    • Complete control over your content and pricing.
    • Freedom to customize your audience experience.

    For most creators, that means WordPress, or it should. Yes, there are easy, “drag-and-drop” ways to build websites, but they limit your options. You can build a paid membership site using Wix, but you have to do it in their one particular way. With WordPress you have several well regarded and time-tested options. And not just for membership.

    WordPress is the Internet’s Content Management System (CMS) of choice, by the way. Some 40% of the internet uses it. It’s not going to go belly up and leave you trying to claw back your own data.

    The WordPress Challenge

    That’s not to say that WordPress is without a few downsides. Substack costs you, but not until you try to monetize, but you’ll pay a flat fee for hosting WordPress (albeit a quite low one) from day one. For the most part, these things boil down to this: it’s hard to get started with WordPress and after you get started it can be hard to maintain.

    WordPress is very secure, but only if you take the time to keep all your related software on track with a steady stream of updates.

    Creators don’t necessarily want to turn into website administrators, but if you’re running WordPress on your own, that’s what happens. Or you can hire an agency or a consultant, but that can seriously undercut the price advantages WordPress offers.

    A view of the WordPress admin area, showing a group of cryptic settings for "Permalink structure"
    Here’s a friendly admin-area screen. Let the fun begin!

    That’s why so many creators stay stuck paying platform fees, even when they know they’re leaving money on the table.

    This Is Where PeakZebra Comes In

    PeakZebra takes the best of WordPress—ownership, flexibility, full control—and removes the headaches:

    • Instant Setup: Your site is live in minutes.
    • Fully Managed: Hosting, security, and updates handled for you.
    • Ready to Earn: Built-in tools for subscriptions, personalization, and audience engagement.

    No coding. No hassle. Just your site, ready to earn from day one.

    We’re launching September 15. Early access is open now.

    Your signup means you’ll receive occasional email updates about PeakZebra products and services as well as access to PeakZebra’s early access program.

  • Stop Segmenting on Meaningless Distinctions

    Most segmentation strategies go wrong before they even start. They sort prospects into neat little boxes based on company size, industry, or job title—details that may look good on a dashboard, but often say nothing about how someone actually buys.

    At PeakZebra, we believe segmentation should only exist to support smarter, faster sales. That means grouping prospects not by surface traits, but by what actually matters: how they make decisions, what their priorities are, and where your product fits in their buying journey.

    Ask yourself:

    • Do these segments respond differently to your messaging?
    • Do they evaluate your product for different reasons?
    • Do they have different barriers to saying yes?

    If the answer is no, you’re not segmenting—you’re just labeling.

    The best segments reflect clear differences in behavior and priority. One group might be driven by speed; another by security. One might need internal IT buy-in; another might sign off with a solo founder.

    When your segments align with real buying patterns, your messaging becomes more relevant, your demos more persuasive, and your close rates stronger.

    Zipcode probably doesn’t matter unless you’re selling real estate. Company size only matters if big companies will solve different problems with your product than small companies. Don’t build for what looks different. Build for what buys differently.

  • What it takes just to get the product out the door

    It’s horrifying to think about the number of times I’ve thought (and said out loud) that I was within three weeks of having the first sales of PeakZebra.

    It’s taken forever, literally forever, and there are reasons for this, some of them good, some of them stemming from deep-seated psychological shortcomings. My therapist long ago came to view the rollout as emblematic of my reluctance to fully commit and dig in to bring a project to completion. He’s not wrong.

    But there were other factors, including some classic entrepreneur mistakes that I spotted pretty early but thought I could dance around without paying the full price.

    The opportunity

    Way back long ago, I was doing some SEO consulting for tech startups and was very much aware of the coming deadline after which Google would start using its new Pagespeed metrics (that’s how long ago we’re talking).

    My thinking at the time was that WordPress would, in many cases, wind up with really poor scores. And I thought it would matter a whole lot more than it has turned out to.

    So I had a solution in mind, namely building static sites using Gatsby and React. I’d make boatloads of money migrating sites from WordPress to Gatsby.

    Google foo

    While I was waiting around for this to happen (and you may recall that Google delayed the rollout of the new metrics more than once), I was looking into WordPress and the still fairly-new block editor and block-based, full-site editing.

    As it became increasingly clear that most WordPress sites would be just fine in the new metrics era, it seemed to me that there was a huge opportunity lurking in blocks. The WordPress world needed blocks, all sorts of blocks. There were already a couple of companies (Kadence, for one) rolling out sets of basic blocks that offered considerably greater design control than the built-in “core” blocks.

    What interested me in particular about blocks was that they were built in a way that made it easy to run code (and even React code) on the front end. They were a clean way to compartmentalize functions in separate blocks. There were capable of doing a whole lot more than just inserting text and images.

    In short order, I had a fairly full (and laughably large) vision of what I needed to build. And I thought I could build it pretty fast. Maybe three months, I thought.

    Lots of things happened in the ensuing couple of years. Lots of development, lots of interruptions, lots of changes in the WordPress world. I’m going to skip those bits for now.

    It changes you

    Getting back to my therapist, what I hadn’t really reckoned with was the amount that I needed to change as a person to stop being a guy coding a big plugin to a guy launching a business. You have a big idea, you’ve spent a ludicrous amount of time and effort bringing it into existence, but putting it out in front of the world and asking for sales is an entirely different proposition. It requires a person that I, until quite recently, just plain wasn’t.

    It wasn’t like flipping a switch. Different views on different sorts of things changed over time. There was a time when I was embarrassed to tell people who asked what I was up to that I was launching a startup. But I got used to that, even embraced it.

    Then I needed to get clarity about how I talked about the product, exactly who it was targeted toward, and so on. You simply can’t go off in twenty directions at once. You have to choose your direct, take the risk in hand, and create the conditions to either succeed or to definitively know that what you had in mind won’t work.

    Embrace the possibility of success

    Strangely, you have to be fully prepared for the possibility that you just might, weirdly enough, succeed. And then you’ll be at the real starting line. You’ll have a company to build.

    I’m not, I should say, a malleable kid still being tossed to and fro by the world. I’m on the far side of a couple of full careers. But I had to become a different person to become someone who launches a startup. I don’t mean that I had to become adept at sales, though being ready to sell is a part of it, to be sure. I mean a different person, a better person, a person ready to live with bigger energy.

    So finally it’s time to launch. You can buy our magic toolkit and build WordPress sites that do things that WordPress sites haven’t been able to do. It’s time to build the coolest things you can think of.

    Now it’s not about solving the problem of how to pull a codebase out of thin air, but rather about the problem of how to get it in front of potential buyers and then close the deal with them. My therapist (who is not, just for the record, ChatGPT) is encouraging me to view it as just another complex problem to solve. Once again, he’s annoyingly on point.

    You, dear reader, can help me with this. Even without becoming a customer (though, couldn’t hurt, right?). You can share your ideas, your confusion, what you like and don’t like about PeakZebra marketing, and so on. I hope you’ll do that.

    Did I mention that prices will never again be as low as they are during rollout?

  • Block-based Forms

    Old-style WordPress forms packages do a lot of things, but then again, they really don’t do a lot of things you’d think would be really obvious. One thing you can’t really do these days is build forms directly using ordinary WordPress blocks.

    Now, there are a good half-dozen prominent forms packages in the WordPress community and some of them are quite impressive and innovative. And free, to some extent: It’s not at all unusual to find that the free version of forms packages will let you collect info from users about just about anything you can imagine, because you can label your fields and input gizmos however you like and interpret the data they collect accordingly.

    But this only works because the forms don’t really do anything with the data beyond emailing it to you.

    And then, blam!

    So, here’s the thing. I’m in the process of putting a forms package into the WordPress.org repo, and it, too, doesn’t do anything with the data beyond mailing it to you.

    There’s a twist, though, for those with a little programming know-how. You give each form a unique name. If you also create a PHP file with that form’s name and put the file in a folder that’s reserved for such things, then this file will execute before the email is sent (if, in fact, you’re having the email sent. That’s optional).

    If you use it this way, then essentially all it’s doing is helping you easily put together a conventional form using normal HTML and the regular submit process. Strangely, this is harder to do than you might think. Most of the other form packages have moved over to REST or Ajax calls to submit their forms. There are some good reasons to handle things that way, but it makes it much harder, if not impossible, to step in and take over the processing once the user clicks ‘Submit’.

    Surprisingly handy

    I was surprised to see that this, all by itself, could be pretty darned handy. My surprise stemmed, I think, from coming at the whole thing sort of backwards. I’d started by focusing on having a custom database that forms automagically wrote to on submit. The forms were just the front end for a system, which was where my real focus lay.

    But just throwing the form together quickly and then not having to deal with the baggage that the form package provider has tacked on (a different add-on for each integration, and so on) turns out to be handy, at least for me. My hope is that it’s handy for at least a few folks out there as well.

    There’s a premium product in the pipeline as well, which I guess is no surprise. It adds in the back-end stuff I mentioned above. And then things get really interesting, but that’s a topic for another post.

  • That Opening Keynote at WCUS 2024

    Ah WordCamp! The event opened on a Thursday and by Friday late afternoon Matt Mullenweg had driven a wedge into the WordPress community that still remains to be sorted out.

    Eventually, I got past the drama aspect of the event and started thinking about the content, and one thing that stuck in my mind was the opening keynote. Joseph Jacks, the founder and general partner of a venture capital group called OSS Capital talked about the difference between what he termed “closed-core” and “open-core” business models.

    I just went back and viewed the video of the talk and I think there’s a lot more to be said about “open core” and how it does and doesn’t work. We’ll get to that.

    The Bittensor bit

    What I also noticed was that there are a couple interesting bits thrown in almost as an afterthought at the end, when Jacks, obviously enthused about the project, took a few moments to talk through what the Bittensor project is.

    He was talking about the way that basing a project on a blockchain can allow a community to enforce that everything that happens on the chain is open source.

    Who’s source is open?

    Jacks said: “It’s also related to something that Matt was blogging about maybe yesterday or the day before which was… we have this kind of phenomenon in the industry where people are trying to say that their models are open source, and they’re really not open source.”

    His example for this was Facebook’s Llama, but it’s interesting as background for the way Mullenweg was thinking about the way that the loose couplings between open source projects and companies that exist because those open source projects provide a platform.

    Couple me loosely

    I think the issue that the WordPress community is concerned about at present is how that “loose coupling” is defined and managed. There’s been a sort of “loose consensus” about what’s acceptable for, say, plugin businesses, but clearly rather different understandings of acceptability have developed.

    It’s also interesting that Mullenweg, on the cusp of attacking WPEngine in no small part because it was now owned by an equity firm that he accused of taking value from the project and community without giving anything back, picked a lead-off speaker who invests in companies that build atop an open-source ecosystem.

    Mullenweg is clearly trying to reshape and tune the loose coupling model–and much of the pushback from a frustrated WordPress community accused him of hypocrisy regarding this precisely. These complaints grew louder, of course, when Mullenweg subsequently took far more active control over the WordPress.org site and its plugin repository. The community understood the .org site to be a community asset; legally it belonged to Matt.

    The question of who governs

    I’m not sure how the rift between Matt and a substantial fraction of the WordPress ecosystem will be resolved, but for me it raises the issue of how open-source projects should be governed.

    Funnily, I had somehow forgotten the tacked-on part of that opening keynote. I was excited to see how there already exists a fairly large open-source project underway that has a radically different governance model. Because what controls activities and decisions in Bittensor is rules built into the blockchain and the possession of the chain’s currency token, the tao.

    “What it also does,” Jacks said, “is it allows the user to basically actively participate in the ownership and governance of the model, so you don’t have a single company controlling the AI that gets produced.”

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