So you've got an idea for a WordPress product, but how do you take it from a rough alpha to a successful launch? Do you release early and iterate fast, or do you polish everything before the big debut? Today on WP Product Talk, we're breaking down the journey from alpha to launch, sharing real strategies, lessons learned, and mistakes to avoid. If you're building a WordPress product, this one is for you. This is WP Product Tech, a place where every week we bring you insights, product marketing, business management and growth, customer experience, product development, and more.

It's your go to podcast for WordPress product owners by WordPress product owners. And now enjoy the show. Hello, everybody. I am Zach Katz, founder of GravityKit. And I'm Matt Cromwell, cofounder of GiveWP and senior director of customer experience at Stellar WP.

And today, we are talking about the topic, how to launch your product. This is the fourth episode of our sixth season of WP Product Talk in which we're going through each stage of building a WordPress product step by step. Last week, we talked about how to create your product's brand and logo, but we need to launch that product. And that's why we brought on a special guest named Jonathan Jernigan. Thanks so much for coming.

Let's bring him on. Oop. Oops. There he is. Hello?

Welcome. Welcome. How are you doing, Jonathan? Doing very well. Glad to be here, and I appreciate the invitation.

Is that the most generic thing anybody says when they come on a podcast? You know what? I just I just asked a question, and that was actually the most unique thing that I've guessed. So no. Yeah.

I question everything. That's and that's kind of what we're gonna be doing today as we're gonna be questioning everything when it comes to what's important and what's not when you are trying to develop your product. So, Jonathan, please introduce yourself and and what you do. Yeah. So I my name is Jonathan Jernigan.

I got started, in WordPress a little over ten years ago now. I spent quite a few years, bouncing around various page builders and eventually kind of found my stride both, in terms of client development and also my YouTube channel on WordPress. In about 2018 when I started creating tutorials on Oxygen Builder. And that kinda kinda got me into the, you know, the the YouTube space, and and that became a a whole driver that I never anticipated that kinda led me to where I'm at today. So nowadays, I focus part of my time on my calendar and my courses, and then I do some very, very light client work on the side still.

I really enjoy staying in tune with, you know, what it's like to build real websites for for clients, partly because it just goes with with the courses that I offer, but, also just because it's fun keeping your your skills sharp. So, yeah, it's been in been in WordPress, a fair many moons. Not as not as much as some folks. There are people that are in it now, I guess, over twenty years. But when I look at the calendar and I see, oh, wow.

We're over ten years now. I'm like, I'm getting old, aren't I? Yeah. It's, we're we're senior word processors at this point. Absolutely.

And as senior word processors, and geriatric, why why are we talking about this, John? And why is this important for, product owners and people looking to, become product owners? Why is this an important topic? I mean, I think probably the most compelling reason without even discussing, like, the the nuts and bolts of how to launch and what to develop and, you know, pacing and that kind of thing would be the fact that a a product affords you the opportunity to to scale in a way that other avenues don't. Like, creating client websites is great, and there are cases where you can charge large, you know, sums of money.

Custom membership sites or, you know, large scale websites you can make you could do only a few a year and make a great income. But, of course, that comes with a lot of other headache and and challenges working with clients as we all know that can definitely bring. Whereas the the, the product side is something that you can be a lot more honed in on. It can be much more narrowly focused, and you're you're able to dictate every part of the the process from what features you build, what you don't build, how you offer support, when. You dictate all of the terms all of the time, and that to me is a a big piece of it along with the fact that it's it's a whole lot more scalable than trying to build an agency to do a bunch of client websites all at the same time.

There's there's different challenges, of course, on the product side. But to me, it's the the challenges are really, enjoyable ones that I I like. Yeah. Yeah. And, you know, I the way that you described how you work with clients to remain in touch with their needs, I think a lot of our WordPress, product owners and budding WordPress product owners have are coming from the client side and and realizing the needs that aren't currently met in the ecosystem and then developing products.

And that's how I got my start, with the plugins that I have and the services that I have. GravityView started because somebody needed a WordPress directory, and that was, not a great there weren't great options at the time. They were already using Gravity Forms, and I said, well, I they were already collecting the data. Surely, there's an easy way to display that. So I built originally, before Gravity View, I built a plug in called Gravity Forms Directory, and I put it on WordPress.org, and it was really popular.

And that was how I knew what people wanted because they would open a support ticket and they'd say, hey. Can you add this functionality? It grew and it grew and it grew as I was doing this all for free, and I realized, oh, shoot. Why am I doing this for free? This is an actual product.

I'm gonna convert that to GravityView. So my path from from, from client work to to having a product went through .org and but then I didn't just, I didn't just develop it myself. I actually hired somebody, to develop the core gravity view because it was a little high a little, more complex than I was used to building. It had a user interface. It had drag and drop.

It it had a bunch of different things that I wasn't familiar with, and I wanted to work with a designer and a developer to do that. So I did. They and then once they had a foundation for it, I built on top of that. Right? But that was the the impetus and and the way that I went about it.

And we're still, to this day, implementing some of the less used features from Gravity Forms directory plug in in GravityView because that wasn't in the 8020, and and and I'm sure we'll probably get to the 8020 rule, later in our conversation. But that's my path from from client work to products. Jonathan, what's what's your story here? Very, very similar. I, came up with the idea for PyCalendar when a a a real estate, client of mine came to me and they said, we need our clients to be able to track these deadlines.

There's these these deadlines in these real estate contracts that if you don't meet and validate the entire thing, which can be, of course, extremely costly for for everyone involved. And they said, we just needed to send some emails, drop some notifications in my inbox or on the website when a certain day arrives to remind you you gotta complete this this item. And I thought, well, surely, there's a bunch of calendar plugins for WordPress. There there must be some way that I can just tie an ACF field or even just a simple little post into an event on a calendar. And it turned out that that was not really what any of the the products out there did.

They all were kinda designed more for live events or, you know, major major kind of, event based calendars with ticketing and venues and all kinds of stuff. There wasn't something that was just really simple and and really flexible. So, it really came which I was thinking about this before we went live. It's it's kind of that super cliche thing you hear people that are kind of on the other side of the product development life cycle, like, say, like, oh, we just we just came across it because a client needed it. And that's exactly what happened for me.

It was out of a direct need that a client had, and that's as I think about it now, it's probably part of the reason why I haven't completely abandoned client work because it just keeps me so much more in tune with what real people need on a, you know, on a real website. So, yeah, it's that it's that generic solving a need that I thought surely there would be a a product that already did, and as it turned out, it did not. So we just happened to to plug that gap. And how did you decide on what the core functionality would be? And how did you decide to turn into a product instead of keeping it as just code for this one client?

Well, the so that that's latter part of your question is basically that I I developed a MVP, using some early ChatGPT assistance actually. Like, shortly after ChatGPT first launched, it enabled me to kinda tie together some disparate systems that was like a a JavaScript calendar library and then some ACF functions that would automatically update, dates based on, you know, math calculations of, like, seven days from today, but not on a Saturday. You know? Like, these different things that I could kind of fumble my way through, but when you start to smash them all together, it got way outside my league. So that's that's kinda how it came together initially.

And then I was, like, realizing, like, this is so cool. This this works so well for me. Surely, if we made this just more simple to interact with and not require you to have, you know, JavaScript and custom functions and all this stuff running around your site, that there would be other people that that would need this. And so I I like you, I went to one of my good buddies and I said, hey. I really need some help on the coding front.

Like, I'd I'd really like to be involved in the architecture and sort of the design of the product, but from the nuts and bolts coding perspective, I'd like you to take over. So we've we formed a partnership there, and that was something that, we we both knew kind of couldn't do without the other. So it was a very symbiotic relationship, and still it's just me and him to to this day. It's just the two of us, and it's such a it's such a joy. You know?

They say don't go into business with your friends, but I'm glad I did. I I I wanna get a little bit more specific. I actually been kicking the tires on my calendar, on for WP Product Talk, actually, because it's cool. It's a cool idea to have like, we have all of our episodes that are all date based. And what if I could have, like, a calendar for upcoming episodes or past episodes?

Like, what what was WP product talk talking about last November, for example? That was a really interesting time to be talking about WordPress. But so the the idea that you can essentially add a date to any post type, in the WordPress website and have that show up on a calendar, that's a that's a cool, unique, feature, that I think sets you apart in a different way. How did you land on that approach specifically? It's it's funny you say that because that was such a core thing before we even start started developing was, like, just how should it work?

And I knew coming into it, just like I already explained, that there was no product that fit the, that that gave me the ability to achieve what I needed for that real estate client, which was exactly like you just described. We needed to have a post that just said, you know, I forget what the specifics of those contract items were, but it's like deadline number one. And we just needed one date attached to that and, like, that's it. So I kinda use that as the foundation to it to think about, well, if I needed this to work, it has to function on a custom post type that I set up and therefore that essentially invalidates all the other calendar plugins because they're going to set up their own events custom post type. Mhmm.

And then I'm I'm locked into that, but that doesn't work for what I needed. So when we started looking at it, we're like, well, why don't we just why why don't we just essentially do what other plugins do and tie in core WordPress functionality? Like, get ourselves in the sidebar, like a category almost, and just work on any post type. And so the name PyCalendar actually comes from originally, we were gonna call the plugin, which I'm very glad we did not. We were gonna call it any post into event, and then we just dropped off the a post into event PIE.

So pie calendar. That's where that came from. And that was the approach. It was like, maybe maybe you have, in your, you know, your default post, maybe you have some press releases that that have a date attached to them, but maybe you also have an event CPT and maybe you also have, you know, like you said, some some podcast episodes and you wanna show this mix of things on the calendar. And so we just wanted to give the flexibility to to basically turn any post into an event.

And we have people that do it in fascinating ways. Some people just use default posts. Some people use their pages. Some people use custom post types. Some people use ACF fields.

It's like you can do you can basically turn anything you want into an event on the calendar. Oh, also products. Do people do WooCommerce products, Surecart products, all kinds of stuff. That's awesome. That's really good.

I I think that's some of the secret sauce of why we want to do this, this topic in particular right now because, at this stage, if somebody's building a new product, you know, we talked about branding. We talked about logo. We gotta start talking about, like, differentiators or or or what's gonna make your product unique, how you're gonna build it out in a way that matters, not that it's just like, you know, to borrow WordPress's tagline, just another event calendar plug in. You know, it there's a million of just another AI plug in right now going on in .org. You know?

But what's gonna actually set you apart, in a unique and different way? So I appreciate that insight. That's super helpful. I I'll say from from from my side in terms of, like, figuring things out. I've said this on the show too many times, but, like, we had a similar circumstance with with Give in the very beginning that, we were serving clients.

We wanted nonprofit, we were serving nonprofit organizations. They wanted a way to give, and it was like, well, do you wanna set up a whole WooCommerce store just to be able to do a donation? Not really. And at that time, Gravity Forms wasn't really into payments all that much, although it was definitely possible. But it wasn't like a robust feature of theirs.

And, and so we leaned in on that quite a bit. We also had a product before the product, kinda like Zach, that, we actually sold a a WooCommerce, checkout, plug in that was a a one page checkout, essentially, because that was how we were trying how Devon, my partner, was trying to help non nonprofits was it was a WooCommerce install, but they didn't wanna go through a cart for a donation. That feels super weird. And so rather than the whole cart and checkout system, you just have a product, which is your donation page, essentially, and you can do the checkout on that product page directly. And that's honestly where the the idea of how we implemented GiveWP came from in the very first place.

And, when we launched, we definitely, leaned in on that. We said we like, I I every once in a while, I go back to the very first video we created with, like, a a Fiverr video person and and a Fiverr voice over person. And, we were like, you don't wanna be just like a simple form plug in, that that that just takes payments and doesn't do anything with your donors. And you don't wanna be a whole giant ecommerce setup. Like, we are really trying to nail that spot between Gravity Forms and WooCommerce.

And we're like, that's where we think the sweet spot is for for nonprofit organizations. And, and it resonated a ton with with folks right out of the gate right away. So, that that process, I think, is super important. It sounds like we've used our guts to determine whether or not what we're doing is, a good fit for, like, product market fit. Did did either of you and, Jonathan, did you talk to other people other than the clients that you have this contract with to see whether or not that this was something that was needed out there?

Like, how did you, get the right mix of functionality outside of just the client that you were working with? Well, I I kind of that's a great follow-up question because I was gonna tie into what Matt was talking about. We are we we were very clear from the outset that this, this plugin originally started just as a free version with the mission to just get something live on the WordPress plug in repository, just to to see what it's like to get something out there to just experience what that process looked like. And then we we were like, well, if if it has any legs in the in the free version, then maybe we can look at the pro version. And we kinda knew pro would have fancy things like recurring events and, you know, WooCommerce support and stuff like that.

But the free version would just be the the most essential piece of this plug in. Very, very, very capable and adept, not artificially, you know, hamstrung just because it's free. But we I I just wanted something that I would want to use. That's that was the other core, like, kind of tenant was, like, if I if I came across this, would I want to use this plugin? And that was like something that we, we thought a lot about was like making sure that it's something that we would be proud enough to use ourselves.

And also, you know, kind of from that architecture standpoint, being very intentional about the things that we did not want to build. You know, we didn't we didn't build it in a way where, you know, advanced products like Bricks Builder can, like, kinda query into the data and those sorts of things. We wanted it to just be, like, this very clear focused, you know, event calendar solution, not a whole bunch of crazy, like, developer features. We've we've gone slightly more in that direction as time has gone on, but, just we my my cofounder and I, Elijah, have this term that we jokingly call the simplicity gun. Like, if one of us comes with up with an idea or somebody asks for a feature, we go look at it and we jokingly say we're gonna shoot it with the simplicity gun.

Like, if if the idea is like a Zoom integration, well, what do they actually want? Like, is it just the ability to drop a link into the event data that connects them to Zoom? Like, trying to figure out, like, what is that piece that we can just continue stripping down to its absolute core into the the most simple as possible, you know, iteration of of that feature or that idea. And that's just that's that's how we were starting from the very beginning was, like, relying on core, you know, block editor components. Like, all of our sidebar controls are the the native, like, you know, block editor Gutenberg components.

So none of that is custom coded. Benefit being that we didn't have to worry about accessibility because all that stuff was already accessible from the the out, from the outset, which is cool. So I guess I'm rambling a little bit, but the idea that, like, we, before we we developed anything, we were just looking at what's the simplest possible functional version of this and making sure that we weren't reinventing the wheel. We could've we could've built our own date picker, but that would have been super silly. The block editor already has that.

And, yeah, I've I've lost the plot of where I was headed, so maybe somebody recover me. No. That's I think that's great because in many ways, that's exactly the purpose of a WordPress plugin is to look at core and enhance it in ways that benefit the end user. What is it in there that that a user wants to do but can't currently, and how can I do that, in the well, I mean, there's a lot of different ways you get to that approach of, like, what's my quickest way to market? What's my my smallest lift I could do?

Or what's the absolute minimum viable product that I can ship? You know, there might be a time at which you find that the core, date picker doesn't serve your purposes, but that will come after tons of experience and feedback from customers, and that's the right way to iterate anyway. So, I think it's great. That's, I think that's a great approach. Really smart.

And I didn't even notice that, though, when I was looking at the date picker because you have a start date and an end date in the, little, block settings. And, I didn't notice that that was the, core date picker. Are the buttons also core? Because they look a little bit different. Yeah.

Those two buttons are not, but basically everything else is. Yeah. Like, all the little toggles and date pickers, the, the little, like, accordions for recurring rules that that expand and contract. Those are all native components. And we did that partly because, like I said, reinventing the wheel, which just wasn't necessary.

But also, like, somebody else somebody else already did the the heavy lifting to figure out how do you how do you make that operate? Just without even looking at, like, the functionality of what we were trying to achieve. You had to figure out, well, how do I make an accordion and a date picker and, all those all those tiny little things that can end up making you spin your wheels and almost never release anything. You had asked, just previously as well about that evolution of the, the, you know, getting getting the product launched. And I touched on, like, the idea that we we began with free, and that was that was our decision to to move forward.

We released the free version. I forget when. There was a gap of about four months, but immediately, we put the free version out there. I reached out to some friends, posted a YouTube video on it, and people were like, wow. This is amazing.

And as soon as we had some positive feedback, it was like there was no money. We didn't make anything off of it yet, but we just realized like, okay. Other people want this. So now we can look at adding additional features like recurring events and WooCommerce support and those kinds of things. But then even still, we we're we're we're super slow to move, which some people dislike, but we wait to see, like, how are people gonna use this in the real world and what features what features do they really want?

You have somebody that emails you and says, for example, they want a Zoom integration. Like, oh, I can build that. But we have a feature request tracker internally, and one person, legitimately one, has ever asked for that. So you could waste a bunch of time going down that route, or you can wait and let, you know, the stuff bubble up to the top. One of which, as an example, that that came, probably after about a year, we kept seeing people asking for the ability to add blackout dates.

So if you have a recurring rule of repeat every one week, they're like, I wanna blackout this one specific date in that interval for Christmas or a national holiday or whatever. And we didn't have that, but we were like, we're seeing this again and again and again. So we're able to to add that in. But that was something I'd never even anticipated going back to the beginning. It's just like, I want recurring events because I needed it for that client.

But they had no use for blackout dates, so I never anticipated that, which was perfectly fine to launch without. So you can definitely sit there and spend your wheels adding custom functionality and things you think people need or you can start super small and and get it out there and just see how people use it in the real world. People are gonna use it in ways you just never expected. Yeah. And did you launch like your go ahead, Zach.

Did you launch with any sort of metrics gathering? Like, how did you judge what people needed only through customer support interaction, or did you proactively ask for feedback? How did you gather, additional information? The the very early stages was before we even put it on the repo, I was sending it to just, like, a close group of friends who I know use the block editor and would be able to kinda put it through its paces. In fact, Kyle from the admin bar is in chat, and he was one of the people I sent it to just knowing, like, he does a lot of event based things.

Like, let me get his take on it Just a couple of other people like that who I knew could potentially try it out and use it in, in a real production environment. And pretty quickly, they're like, this is great. So that super small, like, closed, not beta, but, you know, sort of, like, closed group of of friends or peers that you could share it with to get some initial feedback. That one's tricky because, you know, your friends are probably always gonna tell you that it's cool even if it's not. So probably need to expand beyond just, like, your your close core.

Yeah. But, yeah, I would say to answer your question, it was probably the the close close group of friends that I initially shared it with, then putting it on the repo and just trying to drum up some noise on, YouTube and various posts and stuff so that then I could, then we could, you know, have some some real users that I did not know putting it through spaces. Yeah. I really like the approach of, using .org basically as your initial launch, and validating the idea, essentially. I think that's really smart.

And that is a choice that folks have to consider in one way or another. Like, how do I wanna get out of the gate? How do I what kind of, not just features I have, but what kind of, business model approach do I wanna have at launch? When we were thinking of give, we were we we knew what we wanted in the free plug in, really clearly. It was a little bit unclear exactly the way we wanted to do, some paid options, but we knew that, for example, at that time, a Stripe add on was gonna be the most important paid add on, for us.

Like, we went out of the gate with PayPal only in the free one, at which, at that time, it was PayPal standard. So it was really a clunky experience. But, but and then you're like, oh, or you can, like, have credit cards right on your website, but that for that, you need to get an add on. And so free and a little bit of paid right out of the gate helped us. But I love the ability to, like I said, validate and get feedback based on your, free users in the first place.

You know, way back in the day, people used to ship pluginsto.org not as products at all. They really were basically elaborate snippets of code that were like, hey. This was kind of really useful to me, kinda like GitHub snippets. This was useful to me in a certain way. Maybe it's useful to you too.

And if you have a problem, good luck with that. But, nowadays, people are really expecting, full featured things for free all the time. And I really I I really would like folks to get back to the day of just, like, really think of free free only as MVP as much as possible. Lean, clean, minimal, and focus on talking to those users as much as possible like you have been. I think that's a great approach.

Yeah. I I agree that it's a great approach. And as a developer, I wanna make sure that you're structuring your product so that it can scale to pro gracefully. And there are some different methods of doing this, but one of the kind of most straightforward, I think, might be structuring it so that each feature has its own, files or maybe even its own directory for each feature, and then you can include those as necessary or exclude those as necessary from your build script. And that's just kind of like a development aspect of it because going from alpha where or even just a .org free plugin to going to something that you distribute on your own website people pay for.

There are a lot of technical considerations that go into that. I'd love to talk more about how you chose how we all chose our distribution methods and the technical, methods for going from alpha to actually having a paid product. Yeah. And and while we're on this subject, before we get too deep in one angle, there's the technical considerations of structuring the the plugin files and free versus pro and that kind of thing. And also the the financial side too.

I think that's an important thing that people get hung up on. Lifetime deals, subscriptions, and and that's an angle that that we can touch on. So from from the technical side, what we decided to do was have the free and the pro plugin be completely standalone from each other so that you don't have to have the base free plugin and the pro. They're they're standalone, which if you're looking to kind of, I'll say, game the repo, that was a mistake because Mhmm. Then, you know, if somebody switches from free to pro, technically, you lose an install or multiple depending on how many they're using.

But in the architectural side, that means that they have one less plug in installed on their site. And then if anything happens to .org or, you know, we're not we're not burdened with, you know, coming up with a way to also provide the the free plug in in the future as well. So from from that perspective, it has both advantages and disadvantages. I would say when we saw some of the stuff that took place last year, with regard to the repo, we kinda breathe a sigh of relief thinking, okay. Well, fortunately, our pro version is completely separate and the the free version doesn't have any kind of impact on that, which is nice.

And then, you know, in the code, that's not really my angle, but I do know that there are a lot of things that, that actually exist in both sides that that that's one thing I was saying. We didn't artificially hamstring hamstring hamstring the free version. Instead, all of the functionality not all of it, but some of the functionality is there. You would just need to add a little hook or a function to your site to enable it. But if you want the convenience, then you can just move into the pro side, which then makes it much, much more simple for us to maintain those two separate code bases because they're actually quite similar.

Yeah. I mean, just to back up a little bit, I definitely think there's a lot to that a lot of folks can consider. The free and pro option is one, or free and an add on option is another one, or, or even the way that you have it set up, which I think is free versus pro. Like, a free and pro is basically like the add on model, but you just put everything into pro, essentially, which some folks do. But, and then the free versus versus pro is, like, when you install pro, it deactivates free.

Do you also delete it? You don't delete it. No. We don't do that. We Yeah.

Yeah. Widow Messle and stuff like that. They can just do themselves. Yeah. Hard and scary and stuff.

Yeah. But that and I will like, I totally understand what you're saying about, like, it might feel like gaming the system in some way, But I definitely think active installs are a big validator for customers or for for people in general who are cruising the repo and wanna see whether or not anybody cares or likes this product at all. And the other one that is a little bit strange, is that, like, the .org moderators might get a little bit weirded off if you have, like, 505 star reviews, but only, like, you know, a hundred active installs. They'd be like, where did all these people come from? So there's there's weird quirks of of that, that go that way as well.

But, I I mean, thinking through all of it, it is a business decision for sure. I like the way you think through it in terms of independence, and I, unfortunately, I do feel like every product owner now for WordPress has to start thinking about their independence escape clause in one way or another. But, there's also just the way in which we build the code, to to support each of these different models. Zach, I think that was a little bit of what you were getting into. Right?

Yeah. There's there's building the code, the technical side of it. But, you know, for me for me and I think a lot of product owners, the the concept of distributing the actual zip file from your own website is a real big blocker. And there are some different ways around that. Like, there are different solutions for this.

There's we use easy digital downloads most of the time. And that was, a choice that I made years ago when Kevin Williamson was still running the plug in. We continue to use it today. I think if I were starting from scratch and I'm actually doing this with Datakit, another plugin that we're we're, releasing and, we're using Freemius because Freemius has, out of the box, the ability to ship different zips, based on pro and free features and distribute them. And you don't have to deal with any of that.

You just integrate with Freemius, which is a really nice, nice way to do it. I EDD has given us so many problems over the years. It also is relatively affordable, and, it'll and it has unlimited customization, which can, you know, hurt yourself and if you don't pay attention. Yeah. There are pros and cons to that.

It's very simple to integrate with code wise and we don't currently do anything, too extreme on, the the plugin code itself. But, boy, we've had a lot of issues with up upgrading and downgrading licenses and things getting out of sync, and it's it's kind of a mess. So the the licensing side of things is really complicated. And I think, there's a trend that's starting and we wanna get on this trend, on this onboard this trend as well where you use OAuth and you just have people connect to your own website. Instead of having to deal with licenses, you just have them sign in, and that also has the side benefit of, hey, if guess what?

If you don't have access to the, administrator account, that bought this license, you don't have access to the plug in, which is a good way to get rid of, some a lot of piracy. So those are some some con con considerations that we're taking into account these days. How about you, Matt? Yeah. I I mean, my perspective as of I'll just say as of late, but that is, like, of the last five or six years, is really heavily impacted by the customer experience aspect of all these things.

And the licensing stuff ends up being sometimes, unfortunately, highly problematic, and difficult and challenging. So the one thing I do like about Jonathan's approach with the pro versus free, is that you can kind of bake licensing into a pro version. That's actually the route that we take on a couple of the Stellar products is you you purchase the thing, you download it. When you install the Zip, the license is actually generated in the Zip generation, part, and it just is kind of, like, baked in. You just install it, and it's licensed automatically.

Because you have the whole trouble where, people buy something, they download a zip, they install it, and then they never activate their license. They're you know, until all of a sudden there's a problem. But then by the time there's a problem, they're upset and bothered. You know? So I I really love also the OAuth method.

I think the part about, like, you know, disabling functionality and things is something we should have an episode on, for sure. Because it's it it is complicated, and it's, it it it a touchy subject in the open source space. But it is something that everyone as a business owner has to consider in one form or another. But I also really like I mean, with Give, we decided that it was gonna be an add on model from the beginning. So there was all the core functionality is in the free plugin.

And if you don't have any add ons at all, you have all these features, and and it's really full featured, and there's all kinds of things you can do. You don't need an add on if you don't want. Then all of the add ons, they aren't, like, you know, unique or special parts of a bigger puzzle. They're all, available because of the way in which we made the core, product highly extensible, which I like it as a as an approach. It has of course, I do.

I mean, that's what we chose. But, like, it has its advantages in terms of, like, helping to encourage a large developer community around your product as well, because people can be building out their own individual add ons. And it's one thing to have, like, a bunch of, like, snippets. Like, I could say, personally, in the WP Product Talk site, I don't even have a functionality plugin. I just have one of those code snippet plugins.

And I have, like, 25 different tiny little snippets that are customizing things. Every time I feel like I have to customize, like, seriously simple podcasting plug in, I feel like, oh, why do I have to go and do this? And I have to but if I actually go and build an add on for seriously simple, podcasting, I feel like I've accomplished something. It's a totally different feel, as a as a end user who knows how to extend stuff. But also, if you're gonna go that route, then you have to be willing and open to actually supporting that developer community, which honestly, I feel like give could do a lot better on that front.

And backward compatibility is a big problem, especially when you're trying to get a product from alpha to launch. Jonathan, you you were talking about, just getting things out there, seeing how people like it. How concerned were you with that compatibility? And how concerned are you today if you've made major changes to the code base? I mean, that was for sure a a big consideration early on, which is part of why we started with such a small plug in, very simple, very focused, and tried to rely on things like the the core components we talked about, the core date picker and those kinds of things because we knew somebody else is gonna be doing the heavy lifting on that considering what happens if we change this particular facet about the the calendar picker.

But also from a from an under the hood perspective, there's not really anything revolutionary about PyCalendar. It's just the way that we've architected this experience. Like, for example, when you when you turn on the little toggle that says show on calendar, all it does is just set a little meta field that says py cal show on calendar equals one. Like, that that that's it. You know?

And then we just query the posts that have that particular meta field set to one. It's like about as simple as it gets. So unless there's some, you know, absolutely majorly breaking way that WP query would would change, maybe we would have to do something about that. But most of the thing most of the things that we decided to do were as close to core as they could be and as simple as they could be so that when it came time to, you know, add some additional feature, we didn't have this whole legacy code base to to consider. And we have the advantage of something that's extremely focused and quite small in scope as compared to, you know, a gravity forms or, you know, a give WP that's in in incorporating, subscriptions.

You know, we don't have anything complicated like that. So that was another very intentional decision was not doing things that would be, would be, you know, potentially what am I trying to say? Like, technical debt. Would that wouldn't incorporate a bunch of extra technical debt. And the thing is though, even with a tiny plug in like ours, it's been coming up on two years now, and we're starting to see some of the decisions we made early on were are are coming back to to bite us.

Like, an example is we never anticipated people would wanna put two calendars on one page. That seemed crazy, but people do. And so what it what it what it does is it breaks both calendars when you put two on one page. And we're like, oh my gosh. How first of all, why why did we not consider that?

But it just seemed like a use case that nobody would need. But but as a consequence of that, we'd have to go almost back to square one. So we've kinda just decided, sorry. That's a limitation that everybody's gonna have to live with. And so far, people have been okay with that.

But even with our hyper focused attention to not wanting to introduce technical debt, not trying to, you know, reinvent the wheel at every stage, we still ran into a problem a year and a half later that is almost, like, impossible to fix now. So, you know, there's a there's a balance there where you have to figure out, like, the, you can you can try to make it perfect, but it's just not going to be. In the real world, it's it's, you know, you just have to get it out there and make some decisions. And and also being okay with not pleasing everybody. That's another big big reason we went the approach we did with PyCalendar that doesn't have ticketing, doesn't have payments, doesn't have venues.

People ask us for that and we just have to tell them, no. Sorry. Yeah. And in some ways it makes for a slower growth, but the people who are a good fit for your product are a really good fit when you when you're hyper focused like that. I will say from from the perspective of someone who has had to experience the technical debt problem on the on the on the bad side too often.

Like, I can go down the list. Like, GiveWP has done several big refactors. And, three point o, for example, we actually did it over the course of more than a year, almost a year and a half, most of it under the scenes, under the surface, slowly kind of like pushing out new internal APIs while also shipping out a couple new features. Basically, like, hey, big new feature. Oh, this cool thing that you don't care about, but it's going to change everything in the future.

And that was the way that we kind of rolled things out slowly. It took forever. It took over a year and a half just to get to the point at which we're like, alright. Everything's the same, except it's all different code now. Like, there was it was really not a big, significant change.

It was just internals. Cadence Blocks, also, big, huge change, revolutionized all the blocks. That one went through a huge bunch of hotfixes for a long period of time, because there was no way to anticipate all the ways in which all those blocks that are on all these thousands of sites have been customized, and leveraged, and embedded inside of other blocks that we don't control. It was really a nightmare. TEC, also, tons and tons of refactoring that happened.

Most recent one is Solid Security, excuse me, Solid Backups. That was formerly Backup Buddy, on iTheme's side. And Backup Buddy was a plugin that does backups locally for you on a on a cron, essentially. And that's really not a way to do backups in this day and age anymore at all. And so what were we gonna do to actually make it a viable continue to keep it as a viable product?

It really just basically had to be scrapped. We re really literally the new next gen backups is a whole brand new product that it's just trying to continue as what it was, but it's a whole brand new product. Like, that was one of the times in which we just said, no. Hard pass. We're not going to carry on that technical debt at all anymore.

But the the biggest thing I would say about technical debt, with all those things is I think that when you are a developer founder, like, you have tons of sleepless nights about, technical debt. You're just like, I just every day, we're just creating this debt that I'm gonna pay in the future, and I hate it, and I don't wanna do it. From a CX perspective and, I mean, also a developer, But I would say, yeah. And that's just the way it is. Like, you literally are just going to continue to do that no matter what you do.

That's similar to what you were just saying, Jonathan. And you could try your best, but at one point, it's just going to be too much, and you're just going to have to pull the Band Aid. And I would not try to have sleepless nights over it. You'll make that choice when you have to. And don't do all kinds of weird I've seen so many different products who try so hard to avoid all those types of things to the point at which they don't even ship, what they wanna ship anymore.

It's really crippled their ability to get stuff out the door. And that's, to me, worst case scenario when it comes to that question. I agree. And the there with GravityView, we've we built out so quickly. Looking back, we built out probably too quickly in the first year or so after we launched.

And I didn't have the skills that I needed to build out in a way that was scalable for the future. So I added a lot of technical debt that we are still handling today. We did a big version two point o, release that added on top of our one point o API a bunch of new API hooks, and we've been using both still to this day. We've been slowly deprecating and slowly planning for a three point o that will remove the one point o, but we are still dealing with the repercussions of me doing mediocre code back in the one point o days. So for advice for product owners that are trying to go from alpha to launch, I would suggest, thinking about things from the level of importance it is to the product.

If if this is going to be needed for every single query that you use, for example, pay more attention to it. Give it more time. Let it steep. Ask some ask professional advice if you need to. Ask an AI at this day and age, like, hey, what are some downsides to this approach?

As opposed to, you know, if it's the name of a setting, it doesn't matter. If it's whether or not you have labels above or below, it doesn't matter. All of, like, the little things just scoot right over them. They don't matter. The big questions, though, that's where I would suggest putting most of your attention and effort in getting that hopefully more right than wrong.

You know, we got most we got a lot of things right with GravityView one point o, but the extension of that too quickly, by me, resulted in a lot of cruft that we're still dealing with. So pay more attention when you're adding new code, that is vitally important. And I mean, on that at that end, you got a product to market quickly and Yep. Got real customers paying real money. And, yes, you have some headache now.

But I think the interesting thing about that whole concept is, like, the vast majority of users of these plugins, I would imagine even for something like gravity kit, gravity views, like, that's a pretty complex plugin. You're you're doing some pretty complex things or it's at least capable of doing that. But the people that are using it are may not be developers themselves. They don't really care what's under the hood. Does it do the end result that they're after quickly without a whole lot of headache, without breaking their site, and can they trust that it's just gonna work for the foreseeable future?

I think that's the the most important consideration. Obviously, we don't wanna just cowboy code everything, but the getting it out there more quickly and just making sure that you have something that that solves that that pain point. It's like there's a more root concern than than technical debt because it's it's unavoidable. And, and I actually don't think it's that bad to allow someone or to tell people, hey. In six months, we're coming out with two point o.

It's not compatible with this old version but x y z reasons are so much better and this is why. I think with users that love your product it's it's not out of the question to say, you know, you're gonna have to upgrade. And in terms of the extensibility, I liked adding a bunch of, filters and actions out of the box, like, on from version one point o, even if people didn't want it because I knew as a developer that that's something that I wanted. I would recommend not adding feature filters, not adding actions, and declaring all your classes final by default to prevent anybody from overriding your your functionality with their own customizations. And then if somebody asks for it and then another person asks for it, add a filter.

And that's against my whole ethos as a developer. I I get so frustrated when I don't see a filter. But as a product owner, oof, it would have been a lot simpler if I had known the number of people that actually wanted a filter and didn't have to maintain back compatibility for ten years on a stupid filter that nobody's actually using. And so an amazing point. We shipped with almost no filters in PyCalendar, both in free and pro.

Very, very little. Essentially, just enough to give us things like WooCommerce support, like the the basic fundamentals. We would have people that asked regularly about adding the featured image. On the calendar, if you click an event, there's an optional pop over that shows up and it can show, like, date and time and title and stuff. And people would ask all the time, can we add featured image?

And so at that point, we added a hook so that the featured image could go in the popover. But we didn't we didn't add that out of the gate. I would say now we still only have probably 10 or 12, not that many. But also we we couldn't have anticipated the ways that people would actually want to use those hooks. Like, there's a little there's a little, PyCal info short code slash block that will display, like, on the single post view when this event starts and stops, the time zone, and so on.

Some people some people wanna show the word starts on before the time. Some people don't. Some people want to get rid of the period after the end. Some people don't wanna show the time zone. Some people do.

So now we have a few different hooks for that, but originally, we didn't have any. And so kinda letting real users, like you already said, Zach, dictate what makes sense to add. And you still have the option to say, sorry. That's not something I'm interested in supporting. But when people are consistently asking you for the same things, it makes sense to to appease that because it just makes it better, more flexible, and it it's not that big of a deal to do.

Change some text. Yeah. Yeah. Absolutely. But, I mean, that one, I always I I'm a little bit split always on the on the strings one because technically, you know, if they're internationalized, or, then you they can always customize it that way.

Right. But, but, you know, asking them to, like, install, like, local, what is that? Local local translate? Local translate. Thank you.

Or or translate press or something like that just to change one string. You know? But they can also do it with a snippet, things like that. So but that's also to your point earlier about, like, being able to extend core. Like, we don't think of those as filter they're not filters and hooks, but they are absolutely extensible, just by doing common WordPress practices.

Yeah. And I I I try to think of that from the perspective of how would I feel if I was on the receiving end of the support ticket with that response. Totally. Yeah. I wanna get rid of that period, and I'm telling them, hey.

You gotta go install a logo translate for that to get rid of that one period. It would annoy me so so much so. It would just be like, come on, dude. Like, seriously? So I try to I try to think about it from that perspective.

I ask I ask myself that all the time. Like, if I was on the other end of this support ticket, what would I think? And I go back to, to Brian from Perf Matters. Their their docs are incredible. Their support is amazing.

And I just think about, like, what would Brian do? That's that's genuinely something I think about all the time. Just like I actually I really love what you're saying there because the the mantra in WordPress for so long among developers in particular was decisions, not options. Like, let's be smart and make these decisions on behalf of the user rather than give them options that they actually think they want. Like, that was kind of how decisions not options was often used.

Like like, if we're smart enough, we can do this for them. And, and I love the way you're saying this. Basically, like, rather than that, let's just ask, like, how am I gonna answer a support ticket about this thing? Because that's so very, very customer centric. So I I super appreciate that.

Well, I think it's time for our section of the show, called best advice, where each of us gives our best advice on this topic. And, I'll start. And I think that my best advice is to make sure that your MVP, your minimum viable product, aligns with what people want. I know I've had some ideas that are very specific and very unneeded, and nobody actually wants them. So talk to some people who you feel like are your best customers.

Even just a quick Zoom call or even a a chat on oh, heck, you can DM people on LinkedIn and be like, hey. I I I know you, you I know you use this, plugin that I'm trying to extend. I wanna add this functionality. What do you think? Get some ground truth to it, before you start pushing hard on it because it's more often than not for me, it's a bad idea.

I'm gonna extend your your best advice with my best advice, which is just like Zach says that, you know, build something customers actually want. I'm gonna say build something that you're an expert on. Like Mhmm. I have seen so many folks, what's that phrase? You know, it's not they're not scratching that niche.

They're like a hammer looking for a nail. I'm trying to find the right phrase. And it's it's like basically, like, they're they're trying to create solutions for stuff that nobody's asking for. Mhmm. And And creating a market is hard.

If you're if you're solving a problem that doesn't yet that people don't know they exist, that is not an easy road to hoe. But if you're an expert, if you have expertise on something in particular, you're solving that thing all the time in different ways. Come out of your expertise, basically. Like, have your product come out of your actual lived experience. Not be like, I'm a developer.

I could build anything. Let me go build this thing about Google Maps that I think is super cool, and nobody wants it. You're not an expert at that field. You know how to do it, but, like, it you know, folks are gonna be like, who's this person building this thing? And you're not gonna have the expertise there.

It's gonna in the long run, it's not gonna be great for your brand and things like that. I think I really think, like, building out of who you are and what you have, your kind of your resume, really makes a huge difference, when it comes to, to the longevity of any product. And for the record, Matt's referring to, I believe, a product that, that they had. And it was a very good product. For the record, it was a good product.

It just didn't succeed. Talking about? I don't know what you're talking about. Your maps product? Have you forgotten all that?

Oh, that's true. That's true. It's just it's just like totally background processing. We had too many products that we had and and ditched because it really I mean, they served a need. We didn't know what we were doing.

It was super cool. Nobody cared. Jonathan, what's your best advice? I mean, I I have a lot of products that I have started either never saw the light of day or launched and realized I missed the mark on pricing, benefits, features. One in particular I spent with another developer just in dev time, like, over $10,000 on and and launched.

And I I was I was genuinely on the verge of tears. I was convinced. I was like, this thing will work. It will it will make good money. It will solve this amazing use case.

No one cared. In the first month, there was, like, three people that signed up. And it was hard to to pull that plug and try again. But had I continued barreling down that that avenue pie calendar, probably never would have seen the light of day. So I think getting the MVP launched and out there, but being willing being very willing to adapt quickly to whatever happens.

Suddenly, I found that PyCalendar was seeing some success, so I needed to drop off some client work to be able to fill in the the extra time for PyCalendar, whatever, support tickets, testing, development time, or had it not that oh, that was the only thing I was gonna say. Elijah and I agreed that we would commit to PyCalendar for exactly two years. So by 05/30/2025, we would say, are we gonna continue doing this, or are we gonna wrap it up, close the doors, maybe sell it, get a little bit of money back out of it? And by now, I can confidently say it's absolutely. We're gonna continue.

We we love it. There's a lot of, you know, a strong user base. But I think maybe, you know, being willing to push the MVP out there and commit to it for x amount of time, It's super, super simple. Like, if you look at our initial sales graph, it does this, you know, and it comes down for a while. And now it's like a roller coaster.

It's it's slowly, slowly taking its way up, very slowly, partly because we did not do an LTD. It's just always been subscription. But the get it out there quickly. Don't be afraid to pull the plug. But if it does start to see some success, commit to it for a considerable amount of time.

I I would say in hindsight that, like, eighteen months is probably the right amount of time. If you start to see some users, you hopefully will have enough revenue by then that you won't feel that burnout. The excitement will still be there. And then maybe you'll have a viable product on your hand and you can hone in on that one thing. Stop doing client work maybe.

That's great advice. Jonathan, thank you so much for joining us. Where can people find you online? I have both a YouTube channel and my website, which are just jonathanjernigan.com, and my YouTube channel is also just my name, Jonathan Jernigan. So either way is great to connect.

Excellent. Well, everybody tune in next week. We are going to be talking about how to choose a business and pricing model for your product. I'm super looking forward to that. Same bat time, same bat channel.

So Yeah. And, special thanks to Post Status for being our green room where we coordinate things. If you're enjoying these shows and WP Product Talk, please do us a favor and hit like, subscribe, share with your friends, reference it in your show, your newsletters, and don't forget, tune in next week. Thanks.