Chapters and Episode Notes
0:00 – Intro
2:21 – From Teaching to Plugin Documentation: Beka’s Journey into Software and Product Development
5:00 – Meeting the Demand: SkyVerge’s Path to WooCommerce Product Development
8:20 – Navigating Dependencies: Building Plugins for WordPress and WooCommerce
13:10 – The Long-Term Benefits: Why Investing in Platform Growth Pays Off
19:05 – Tapping Into Existing Ecosystems: Marketing Strategies for Businesses Built on Others
25:05 – The Marketplace Dilemma: Security vs. Dependency
28:16 – Tech Risk and Keeping Pace With Evolving Technology
30:07 – Streamlining Development: Building a Plugin Framework for Efficiency
35:05 – Investing in Tech Infrastructure: When and How to Make the Move
36:18 – Knowing When to Pivot: The Art of Quitting and Focusing on New Opportunities
42:02 – The Impact of Marketplace Changes on SkyVerge: Exclusivity, Customer Relationships, and Standing Out
43:34 – Expert Perspectives: Key Insights for Developers Building a Business on Plugin Ecosystems
44:39 – Outro
Transcripts
Beka: You know, I’m very much a proponent of ‘move fast and then iterate’ because your speed of execution as a small engineering team is your superpower. If you can’t have enough, you know, bites at the apple, enough swings, you’re just not going to be successful. So your ability to, like, throw out a crappy product at first is great. And I think our team record was 12 hours of engineering start to finish to launch a payment integration on top of that.
Patrick: Hello, listeners, and welcome to the plugin.fm podcast, brought to you by Freemius. In each episode, we sit down with influential makers, bootstrappers, and entrepreneurs to explore the strategies and practices that have helped them succeed in their business journeys. Our goal is to give you actionable tips and tactics so you can apply them to your own business and product success. I’m Patrick Rauland, and today, I have the pleasure of hosting Beka Rice, the former head of product at SkyVerge, a leading vendor on WooCommerce.
Now, Beka’s path to product development has been winding. She started out as a certified chemist who taught high school-level chemistry. After teaching, she worked across every part of software development, from support and documentation to engineering, and is now a senior director for product management at GoDaddy. She’s also a seasoned traveler who has traversed the US with nothing but two suitcases. Although these days, she’s more often camped on a playmat with her two small children. Adventures aside, Beka loves to figure out how things work, a trait that surely played a role in her taking up product development.
On to the topic of this episode: as the WordPress market matures, we are witnessing sub-ecosystems form and evolve around mega-popular plugins like WooCommerce and Elementor. These market leaders have millions of active installs, offering lucrative opportunities for makers to build add-on businesses and extend these solutions. But many overlook the fact that extending these juggernauts generates double dependency, which comes with many benefits but also more risks.
We invited Beka to share her story and learnings building SkyVerge, a mega-successful eCommerce business on top of WooCommerce and Shopify. And that business was also acquired by GoDaddy a few years later. Beka, welcome to the show.
Beka: Thank you. Yeah, that was quite an introduction. I appreciate it. I’m done. I have nothing left to say.
Patrick: Excellent. All right, we’ll call it now. Yes, we like to make sure we build up our guests with a proper introduction.
Beka: Thank you, I appreciate it.
Patrick: Yes, so I think the first thing that we just want to get into is: how did you get into software and product development?
Beka: Yeah, so I was teaching high school chemistry, as you said, when I started using WordPress. So, I used WordPress to manage my classroom website and my website for the sports I was coaching because, at that time—and this makes me feel old to say—but at that time, learning management software wasn’t great. So, like, you might have had access to Blackboard as a teacher, but it could be kind of cumbersome to manage, and you didn’t really have a lot of flexibility in how you set up the online part of your website. Whereas I wanted, like, you know, extra resources or videos or things that were just a little more interactive for my students, right? So, I started to use WordPress then and kind of got proficient as a user. And at the same time, my husband had been working on an e-commerce site for a small pharmaceutical company and launching their direct consumer sales. In his research, he went through a lot of different options at that time, like Shopify or Spree Commerce and a bunch of other options, and found that he felt like WooCommerce was going to be the best bet for them with what they wanted to do and how they wanted to use the site and how they wanted to be able to market to their customers. So, he kind of was going in his direction doing that, and with a partner, sort of started building e-commerce solutions. I was still teaching, and at some point, they were like, ‘Hey, we need help from here teaching people how to use these plugins, you know how to use WordPress. You know, why don’t you start writing documentation and helping people use the software?’ So, that kind of got me out of my teaching bubble and into the software bubble. And the rest is sort of history from there.
Patrick: Was that, like, so, was that like, I don’t want to say a full-time job, but did you have to, like, stop teaching to start doing plugin documentation? Or was there, like, an overlap of a few years?
Beka: Yeah, not a few years, but like months, for sure. So, I was doing it just part-time, like, sometimes nights, weekends, whatever. I was also coaching varsity sports too, which is also kind of like a second job. And it got to a point where it was like, ‘Well, this is way too much, you know. I can’t do this. I can’t work all the time.’ And I’m sure you know this from your experience in WooCommerce, Patrick, but as soon as you start writing documentation, you can help answer support questions. And as soon as you’re answering support questions, you know you’re kind of starting to delve into product management and, like, ‘Hey, here’s how we need to evolve the product,’ right? So, at that point, I really started to evolve into multiple roles. And it just made sense then, say, ‘Hey, let’s leave one full-time job behind and start and pick up this new one.’”
Patrick: Got it. So, you were part of the SkyVerge founding team. Did you choose to build on top of WooCommerce, or was it more of a happy accident?
Beka: Time, it was just right place, right time. So, the other two partners in SkyVerge, Max and Justin, were working together as I came on to help with documentation. And at that point, Justin had worked with Magento, Jigoshop, and WooCommerce when it was launched, and Max got into it from the user perspective, using WooCommerce to launch their own direct consumer website. So, WooCommerce sort of became a natural fit for them, just having used it and seeing, ‘Wow, this is really flexible, and we know WordPress, and you know you can figure it out pretty easily.’ So I think it was intentional with WooCommerce, just knowing what users needed and feeling like, ‘Hey, we can build on top of this.’ I think Max actually got into it initially because he needed a Kissmetrics integration for their website, so he built one. And then 80 had reached out to him, was like, ‘Hey, maybe you should sell this instead of putting it on WordPress.org,’ and I think he got, like, two sales the first month and was like, ‘Wow, this is 50 bucks, that’s amazing!’ So, we all kind of fell into it from there.
Patrick: Oh, very cool. I do feel like a lot of WordPress developers made something for a client, and then they abstracted it and made it work for anyone. And that just seems to be, like, the best way to get, maybe not the best, but a very popular and direct path from doing client work to doing product work. It’s just, you build this thing, you realize, ‘Oh, lots of people need this thing,’ and then you’re able to sell it, and it just seems…
Beka: We did so much of it. Yeah, we did that early on. So, Justin initially did client work for Max. Like, one of the first things they worked together is still the cart notices extension for WooCommerce today, right? Just being able to do timely, just-in-time recommendations. Yeah, and I think, God, there must have been at least eight different SkyVerge plugins that started out as a client project that evolved into something on the marketplace.
Patrick: Got it. So, let me just ask you then, when was the first time that you built something for WooCommerce, which had no interaction with your clients? Like, how far into this journey were you before you just knew that the demand from WooCommerce was big enough that you decided to do it anyways?
Beka: It was pretty early on. It was probably one of the payment integrations, I’d imagine just because early on, it was like, ‘Okay, everyone’s going to take payments on their website, and they might not always use different functionality extensions, but everybody’s going to need payments.’ So, I think, you know, I don’t remember exactly which plugin it would have been, but it was very likely a payment gateway. But we came into it a few different ways, right? One was things that clients bring to you that you see an abstract use case for. The second was, like, net new things, like you’ve mentioned, which is, you know, okay, what’s the need that people are gonna have? Let me build this net new. And then the third were things like, uh, that we actually acquired from other developers. So, we did a lot of buying extensions that people built early on, or like, at that point, you would submit an idea card to be able to get the vendor rights in the marketplace, and we would buy those cards from people too.
Patrick: Yeah, I definitely want to get into that if we have time at the end. I’m super interested in buying other people’s extensions. But let’s talk about product development. If you’re a software engineer and you want to build not just on top of WordPress, but on top of another plugin like WooCommerce, what technical considerations or complexities do you need to be aware of?
Beka: Yeah, it’s very different, right? You have, kind of like you said earlier, that double set of dependencies where you have to know WordPress deeply, and you have to keep up with the WordPress core development changes. But then you also have to do that with, you know, WooCommerce, which is essentially the platform you’re building on, and WordPress is their dependency. So, you have to, you have to know both deeply. And I’d say that, you know, if I were a developer today looking to get into that, I would first accept that you’re going to have a lot of technical investment and learning multiple different stacks like that that you’re gonna have to be aware of. But then also understanding that with something like WordPress and WooCommerce, where it’s open source in particular, you don’t just have to know your dependencies, you have to know that the interoperability of that ecosystem is a key reason people care about it. And so, when we got into it, our dependencies aren’t always just WordPress and WooCommerce, but it’s every other extension that merchants want to run on their website alongside ours, and the expectation that those will play nicely together and, in many cases, actually work cohesively together. So, I’d say that’s one of the biggest technical considerations, is are you willing to commit to that level of interoperability.
Patrick: Got it. And, and so let me just put this into layman’s speak here. You want to make sure that your plugin works with every other plugin in that ecosystem. So, if you make a recommendation or as much as possible, it’s like the cart notices should also work with some other just-in-time system, and your Kissmetrics integration should work with, I don’t know, Google Analytics or some other analytics thing where the data goes back and forth easily.
Beka: Yeah, there’s certainly limits to it because, you know, the beauty of WordPress is there’s like an infinite number of plugins, so it’s not always reasonable to do everything. But I think that was our biggest commitment: when we built WooCommerce Memberships, it’s got to work with WooCommerce Subscriptions and every other team at Gateway and the other plugins that do pricing, like Name Your Price or Dynamic Pricing. Right? When we built, a great example of that was we built a PDF Product Vouchers plugin, which is kind of like a vouchers and gift certificates plugin, and that had to work with Name Your Price because people often want to sell a $100 or $200 certificate or write in whatever price you want for the certificate. Right? So, that ability to know the landscape of the ecosystem and how you can plug into the ecosystem rather than just acting like you’re on your own island, I think, was one of the things that was sort of important to our success: knowing that you’re in, you’re part of a bigger thing that you need to tap into.
Patrick: What about managing, like WooCommerce itself? Like, you know, because I, there’s a lot of WordPress plugins that don’t get updates. WooCommerce is always updating all the time with new features and bugs and updating minimum PHP versions, all that stuff. And that’s different than WordPress, right? So, WooCommerce might have totally different PHP minimum requirements than WordPress does. So, what about managing two different dependencies that way?
Beka: It’s much better now than it used to be, right? In the early days of WooCommerce, 1.6 to 2.0 or 2.0 to 2.1, or, you know, 2.6 to 3.0, these were just significant and very difficult dependencies to manage. So part of that is kind of understanding where those same boundaries are on what you’re going to support but I would say with WooCommerce, you know, their speed of development has actually been a good thing because they can’t take the approach toward breaking changes that they may have in the past, right? Where it’s like if you’re gonna have a fast development cycle, you can’t expect developers to be just constantly responding to what you do with their products or their client work. So, in a sense, it actually made our jobs a lot easier, right? We had to monitor it. We’ve also, as an entire ecosystem, invested a lot more in automated testing over time, which helps a lot. So, like, our best suite will often catch things for us before we do any manual testing. Right?
Right. So, I’d say that, these days, rather than necessarily having to have a lot of active user testing and, like, you know, really, really deep engagement with the core ecosystem, we can more so monitor it and then rely on automated testing and the stuff that’s shared publicly to understand, like, okay, how are we going to make sure that we remain compatible with this ecosystem? So, it’s still conscious and it’s still intentional on our part, but just these days, as the maturity of software development and WordPress has increased, it’s a lot easier.
Patrick: Yeah, I’m just going to keep asking some little side questions here. So, WooCommerce and many WordPress plugins are open source, and, especially WooCommerce, has added some big features like the REST API. I think Sky Verge was heavily involved with the REST API, if I remember correctly, and really cool. It’s not just, you know, minimum versions and the function names are changing, but there’s also the ability to, like, build infrastructure that your plugins might need or some future plugin may need. How much, here’s the weird way of thinking about this. How much time do you spend working, contributing to the foundation, the platform, so that you can, you know, the platform continues to grow? And, or, do you just sort of, you know, part of me says, ‘Well, I’ll be hands-off. I’ll let them grow in whatever way they want to grow, and I’m just going to manage my little PayPal Gateway over here.’ How do you think about contributing and growing and advocating for a platform to grow in the direction you want it to grow?
Beka: Yeah, early on, you know, obviously when it was a more immature platform, very heavily, right? Like you mentioned, the REST API, you know, which our team did build, like the V1 REST API, for example, and heavily contributed to a couple of other versions. And I think the initial version of that was about, it was somewhere between 60 to 80 hours of engineering time, okay? Which is like a very substantial contribution for a company of our size at that time. So, when it was early on, you could more actively contribute to the direction of the platform. We invested a lot of time into that. Like, you know, REST API, webhooks, the unit testing infrastructure, like there were a lot of things there that we knew we needed out of the platform, and that if we needed it, other developers would need that. And so, those are things we kind of contributed really heavily over time. As the product gets more mature, and also, you know, I think the commercial interests around it have changed substantially too, right? It’s a little bit harder to understand the roadmap and where it’s going. And I think that there’s been some really cool recent changes now with, like, WooCommerce themselves sharing that out a little bit more, and also, developers just starting to get a better understanding of how to contribute. Like, for example, we’ve built a lot around product review management, which was sort of immature for a while. But then, you know, a few major versions back, we contributed an enhanced review system to WooCommerce core to, like, bring product reviews more as a first-class citizen, and just instead of, like, pseudo-comments, right? And so, like, at this point, we still look for those opportunities where, like, there’s something that makes sense for the entire ecosystem, and we try to work a little bit more closely with WooCommerce on those. But I’d say that as a developer, the opportunities are a little bit less, I think, now, just because of the maturity of Woo. But if I were looking at a new ecosystem, it would be a big part of my strategy because you can help drive those things that give you foundations to drive your products forward, but then you’re not solely on the hook to maintain, right? We couldn’t maintain our own REST API plugin for WooCommerce and evolve it as quickly once the rest of the community got their hands.
Patrick: Certainly, when a platform is early, it is nascent. It’s the best time. You’ve the most agency to change things for the better and shape things. And there’s also, there’s less, you know, WooCommerce is much bigger now, right? There are so many people involved, whereas it used to be a little bit smaller. But it’s really cool and powerful that you can contribute to a platform and grow it. And like add a REST API for every developer, but also, it’ll help you build whatever your next product is. I think it’s really cool that there’s that agency. And, part of me says 60 to 80 hours is certainly a lot. That’s two full working weeks for a developer. And of course, there are emails and other stuff that has to get done. But like, for two weeks…
Beka: So I was one of the principal founding developers, right? Yeah, it’s a lot of time.
Patrick: For a senior engineer, it’s a lot of time, but it’s also like, we’re not talking six months. It feels like that’s what I would spend on a pro bono project back when I worked in my agency days. It would be like, here’s a two-week project. This is how we contribute to the WordPress ecosystem. It helps everyone and it helps our business.
Beka: So yeah, well, at that point, it was also a little bit of like cowboy coding too, right? It was a read-only API with no test coverage. So, you know, it’s gone a long way since then. But I think one of the things that might be hard for people to think about too is that when we thought about those contributions, some people would feel like, well, that’s kind of against my commercial interests, right? Like, why would I contribute this for other people when I could build this as my own product or my own thing? And I would say that just to kind of tap into that a little more, the two things that we found important were number one, it elevates your status in the ecosystem to where you can help contribute and drive the project to where you see and need it to go. If you’re dependent on that project, and we knew that if we were going to build WooCommerce extensions, the success of that ecosystem was inherently linked to our success, and we needed to help drive it forward. But the second was, you know, we looked at it from a rising tide lifts all ships mentality, that if I can grow my piece of the WooCommerce ecosystem, that’s one way I can grow my business. But if I can grow the WooCommerce ecosystem overall, I’m going to make a lot more money long term. And so, I say that if you are a developer who’s looking at that mindset of, you know, let’s say I’m building on top of LearnDash or Lyft or Elementor or one of these ecosystems that has these add-ons and extensions, growing the entire ecosystem is going to benefit your business and is a commercially great reason to go all out about.
Patrick: Yeah, that is counterintuitive. I totally get how well it goes against my immediate commercial interests, but long-term, the platform makes you more money than one extra little..
Beka: The growth of the platform is going to make more money for you in the long term than any marginal gains in, you know, market share that you could have.
Patrick: So, this is a perfect segue. So, how do you promote a business that’s built on top of another business? This may be a more interesting way of asking it.
Beka: Yeah, the biggest benefit is captive audience, right? So, there’s a lot going for you in that if I build on WooCommerce, I’m already tapping into a number of people who have decided WooCommerce is the solution for me, I want to use WooCommerce, and everyone else in this ecosystem has essentially helped me to educate my customer around that solution being important to them, right? So, you kind of get to ride a wave, in a sense, that you have some of the marketing done for you just by tapping into an existing space versus creating demand from nothing, right?
Patrick: So, there are already tens of thousands, hundreds of thousands of people using WooCommerce. They will obviously go to WooCommerce.com and find whatever your, you know, your extensions solve in the directory and then buy them and install them.
Beka: And there’s certainly a marketplace place side of that from the marketing perspective too, but I mean just in general when you decide to tap into an existing ecosystem, right? Like, let’s say, you know, it’s WooCommerce plugins or Shopify apps or whatever it is that you’re building, right? Elementor add-ons, you already have an audience that’s aware of and educated on a specific problem and looking for solutions, and so you’re getting them in a buying mindset, yeah, which is really helpful for you because you have to do a lot less work on the marketing front.
Patrick: I’m doing a lot of SEO research and work right now, and basically, I think when you do marketing, the people are so close to already buying, you just need to say, ‘We offer this thing, it has these four features, it integrates with a product,’ and I’m guessing that’s enough of a sales pitch that’ll convert a lot of people already because they’re so far down the buying journey already. Wow.
Beka: Absolutely. And I think when you look at it too, then like everyone who writes, you know, content about the WooCommerce ecosystem or enters this ecosystem and solves different problems, right? All of that content is just enhancing the ecosystem and again, lifting the tide, right? That is going to raise my boat too. So, I think from a developer standpoint, you see that, like a community for lack of a better word, only helps you from a marketing perspective, and you get the buyer at a part of their journey where it’s much easier to close the sale, right? You’re not educating, you don’t have to have as many touch points as you do with, you know, let’s say selling email marketing, for example, or something a little more abstract, right? Where it’s like, ‘Hey, I need to educate you on this problem being something you need to solve in the first place, and I need to educate you on why what I’m doing is going to be better for you to solve it than what other people might be doing.’ So, you kind of get a little bit, I think, of a leg up in your marketing. It just ends up taking a different shape when you’re part of an existing ecosystem.
Patrick: Got it. So let me just ask, does all this apply only for official like, oh, like there’s the WooCommerce.com store, and there’s, you know, if you’re Ninja Forms, there’s a Ninja Form extension, like every little platform has their own little marketplace, I don’t know if that’s the right word, or does this also apply if, let’s say, you make a plugin that extends another WordPress plugin and you just put it on WordPress.org, and there’s a pro version that people can also buy? Like, does this only make sense if it’s on the official marketplace, or does it still make sense if you’re on the open market and you’re selling it yourself through your own website?
Beka: Well, it’s helpful to look at that staying just a week. That’s where a ton of developers wanted to market their products and be in there, assuming that like people will go to that as a source of truth and then purchase from there, and it was a fan, it’s a fantastic business way to make money because that does hold true. But if that were the only place people look for solutions, then companies like if would have never gone anywhere, you know, and then being acquired is clear validation that when you have the ecosystem, you can ride that wave even outside of those channels, right? Otherwise, that company wouldn’t have been worth anything. But the fact that they were successful and acquired by, you know, Bluehost or kind of shows you that that’s feasible and possible. Right? I’d say the broader WordPress ecosystem, when you talk about like, well, what if I just make some plugin on wordpress.org and have a pro version, I think it depends on whether you’re talking about being in a blue ecosystem or like you want to create your own bookings plugin or something, right? An appointment scheduling. Then I think, to put it concretely, I think it’s a little bit harder to ride the WordPress wave as an ecosystem than something a little more niche, just because of how big WordPress has gone.
Patrick: Got it. Let me ask this question in a different way. How did SkyVerge think about this? Because correct me if I’m wrong, I assume that SkyVerge, if I remember correctly, was exclusive for almost all of your plugins through WooCommerce.com. Was there any reluctance or hesitancy? Was there anything to consider? What did you guys think about when making that decision?
Beka: A marketplace is a huge shortcut for marketing, right? Right. We had some plugins that we sold directly to consumers on SkyVerge.com that we moved to the marketplace. And in doing that early on, we saw a significant change in the amount of sales that we produced from those plugins. So we moved everything at that point onto WooCommerce.com just because their ability to generate traffic and eyeballs, and especially the curated and small size of the ecosystem, just led to much more highly qualified traffic and sales than we could produce on our own at that point. So early on, we decided, “Hey, let’s double down on the marketplace exclusively,” even though we know that we’re giving up certain customer touchpoints here that are important to us. The revenue was worth it long term. You know, would I make the same decision again? I don’t know. I think the customer relationship aspect of it is sometimes challenging when you don’t own that relationship fully. But at that point, it allowed us to grow a lot faster than we would have otherwise.
Patrick: Yeah, if we have time, we’ll come back to the customer relationship because I think that’s a key thing for your business health long term. But let me just, I think my one concern is, and maybe other people’s concerns, is then you are at the behest of the marketplace. So, is there ever any work, like was that also a factor of like at any point? So here’s what I’m thinking of, you know, way back in…
Beka: Like Amazon doing AmazonBasics versions of what you do.
Patrick: Yes, or they’re just like, “Yeah, we want to do this now, we’re kicking you off.” Like, is there any concern about that?
Beka: I think there was, for sure, especially as we, especially early on in the process. Right, over time, that was assuaged for us in a few ways. One was, we felt like you have to build your own brand because brand is going to be the backstop against that. And so, if you did get kicked off, you’re not going to recuperate 100% of those sales, but you will recoup some part of it, and you will have some agency there because of having a strong brand position in the space. But then, over time, it was also just scope of what we did became bigger, and so it would have been really hard for someone else to absorb that and to build products to the same scale we had. So, I’d say there are existential threats in marketplaces like Amazon or any kind of private label brands doing what you do matters, but I would say then, you know, your brand is a way you can counteract that and build some security for yourself.
Patrick: Yeah, branding long term always seems like something that’s worth investing in. It always feels not good to invest in everything short term, right? Yeah, and yes, it’s nebulous what value you get out of it, but if you ever do get kicked out of a marketplace or the marketplace world changes, the brand is something you can fall back on if you need to.
Beka: Absolutely, like, you know, when I go to Amazon to buy something, if I’m looking for a specific brand, I’m not going to buy the Amazon Basics version. And so, I think we didn’t value our own brand early on as much as we could have, but then obviously over time, try to do a lot more content marketing, WordCamp sponsorships, like a lot of things to build that ourselves.
Patrick: I guess that’s another advantage of the marketplace is you don’t need to worry about the brand immediately. I think with most businesses, you do kind of need to worry about brands from the get-go. But if you’re in a marketplace, I think brands might come six months, 12 months down the line when you think about having a little bit more time to think about it. You can just develop extensions for a short period of time, get really good output, and then figure out branding stuff later.
Beka: It’s an excellent shortcut, but there are trade-offs to it, like anything, right? Where you get a more immediate influx of revenue due to the eyeballs and purchasing journey being, you know, largely solved for you, and you can more rapidly improve products with that influx of customer feedback. Yes, and so I think there are definitely benefits to it, but yeah, you risk things in terms of customer relationship and needing to build a brand just as intentionally as you would if you sold direct versus in a marketplace. And these are things that are, you know, they apply to e-commerce sellers, they apply to software developers, they apply across the board.
Patrick: So this is another good segue here. So, I think building any business always comes with risks and pitfalls. What were some of those risks and challenges that you faced with Sky Verge and maybe also the WooCommerce marketplace but Sky Verge in the WooCommerce marketplace?
Beka: I think the marketplace selling is certainly a risk, right? So we’ve kind of touched on that a little bit already. I think the risks to us were that we were tied to the success or failure of WooCommerce, which is why we felt like we should invest in the platform itself. I think early on, we also felt like lack of diversification of our revenue would be a risk, which is why we got into Shopify, kind of like placing multiple bets. I don’t know if I again would have done that the same way today because I did, at that point, I think a cross-platform strategy can be really great because it encourages you to make your product a platform in and of itself, right? So that you can integrate with multiple different platforms, that encourages you to separate out things from WordPress that you would inherently store there and use WordPress’s core data models for. But I think that’s really hard to do well and still respect that interoperability that people come to the platform for. So, there’s, you know, we could call that a tech risk, right? In our early days, we weren’t really always sure how to handle it. The marketing risk and brand risk of just selling in the marketplace were big ones. And I think the one risk we did handle really well was that risk of how fast technology moves and can you keep up with it. And I say that was one where we felt like that was really easy to control. So we invested a lot in keeping up with WooCommerce, keeping up with WordPress, contributing to and shaping those.
Patrick: So can I ask, how do you manage that risk? Is it, so my brain is always, I want to hire a specific person who just does all of our updates. Does that work? Or is it, you know, do you divide that responsibility out among the team? And also, at what point did you start hiring others—I know you hired other developers at some point—at what point did you start hiring other developers to help you with maybe QA testing and updates and all this technological stuff?
Beka: Yeah, I think early on we were more functionally oriented than a lot of small companies would have been. So, a lot of times with a portfolio of products that we had, you might say, “You’re responsible for this plugin, you’re responsible for this plugin.” I think to both Justin and Max’s credit, but probably more so Justin, you know, he came at it from a very classical mindset of, there’s a lot of things between plugins that we’re going to do very similarly. So, let’s pull this back into a framework that we can use and apply to all these plugins and reduce our maintenance burden.
So, we had people who worked on that plugin framework as our foundation, which Justin did, and then he passed it to Chase, who still works with us, and said, “Okay, you handle all the base layer stuff that’s common, like activation and lifecycle routines and that kind of stuff that every plugin is going to need to do.” And then the team worked on all the plugin functionality on top of those things.
So, it wasn’t one developer is responsible for new features and one’s responsible for fixes or this or that. We would kind of rotate between things, make sure that every developer on the team had a lot of proficiency and a lot of context between different products. And the reason for that was that we felt like it gave them that sense of how to even better abstract things and how to see the commonalities between those different projects.
So, I think one thing early on was we did have a really strong engineering culture in trying to develop well-rounded full-stack engineers, and it allowed us to move more quickly as a result. Over time, then you have to, you know, doing that in terms of then being able to do it more as a team and to accelerate progress and have, like, four people work on something instead of one, that was a new challenge over time. But I think that engineering rigor was something that we focused on very early and benefited us a lot.
Patrick: Yeah, but it’s interesting in the WordPress space, I kind of think engineering rigor is a little bit lower than in some other software fields. There’s a lot of cowboy coding, and there’s a lot of just, you’re just, you know, copying and pasting stuff from Stack Overflow, probably ChatGPT now. But I definitely remember seeing the Sky Verge like a plugin framework. I can’t remember exactly what it was called, the Sky Verge plugin framework, and it was just everything was clearly organized. And while I’m sure that took some organization time, I’m sure it definitely sped things up on the WooCommerce side of things. Each plugin was totally different, and so it meant, you know, this plugin updates this way, and you have to read the code to figure it out. Whereas, and it sounds like that work up ahead of time for Sky Verge was, it definitely paid dividends over the long term.
Beka: Oh my God, yeah, so much. It was something we used to really handle WooCommerce compatibility more easily because all of these plugins doing everything in a shared way, we could then put that compatibility stuff into the framework, and then you had minimal updates across those 50-60 plugins. Yes, as a result, and it made development of new stuff a lot faster when we did have things to jump on. Like, we kind of made payment gateways a bit of a niche for us, and I think our team record was 12 hours of engineering, start to finish, to launch a payment integration on top of that.
Yeah, and so now mind you, again, that’s like Max writing the code for it, so it’s one of your principal engineers, basically. But, just doing that level of abstraction around your work, I would say, you know, my takeaway from that as another developer would be to invest in like your tooling and your abstraction. And I would say if you don’t get that rigor from the WordPress base, even though it’s gotten a lot better, you know, dip into Laravel. That’s a great way to start to expand your horizons a bit.
Patrick: Yeah, I guess, so let me ask you this, we have a lot of WordPress product people, software engineering people who listen to this. At what point do you invest in that? Because for me, it feels super risky to invest in that, especially with product number one. You just have no idea if it’s going to work or not. Like, is it by the time you get to, you know, plugin number five, plugin 10, plugin 80? You know, at what point do you start investing in that tech infrastructure?
Beka: It depends on what level you’re investing in, but I would say even with plugin one, understanding how your software might evolve and just structuring it in a supportable and maintainable way for the long term is really helpful. A lot of people write something that scratches their own itch, don’t think about where that would go in the future or the supportability of the changes they made. Like, “Oh, I’ll just add a setting for this.” It’s going to be really hard to take that away if you ever want to take it away. It’s going to be very problematic. So, I would say always make those investments and just try to streamline where this software is going to go. What are some things I can do now that might facilitate that in the future? But then in terms of abstraction and sharing tooling, yeah, definitely not useful with one plugin. But if you want to build a lot of add-ons, which is usually the strategy if you are building extensions or add-ons, once you get to three, four, start thinking about that.
Patrick: Yeah, I will say my first version of any plugin is super rough, and I will, you know, I do remember some of them. It’s like, “Well, let’s see if it sells. If it sells five, ten copies, like, okay, now I actually need to make this code readable, understandable to me a year from now, so I can update it.”
Beka: But that’s a great way to do it, right? You shouldn’t, you know, I’m very much a proponent of like move fast and then iterate because your speed of execution as a small engineering team is your superpower. Your ability to have, you know, I love, forgive me all of you non-US people, but to use a baseball metaphor, right? More at-bats, you’re going to get more hits. And so if you can’t, if you can’t have enough, you know, bites at the apple, enough swings, you know, you’re just not going to be successful. So your ability to throw out a crappy product at first is great, but then you need to know how to turn that into a really good sustainable long-term product too.
Patrick: Agreed. So were there any other key moments or decisions that helped Sky Verge grow? Any other key decisions that helped Sky Verge eventually get acquired?
Beka: Oh yeah, I think there is. There are a few things that we did a little bit differently than a lot of companies. So, one was that investment in our shared infrastructure that allowed us to move a lot faster into scale, a portfolio in a maintainable way. I mean, that was kind of a really important decision early on. Like WooCommerce themselves, for example, I don’t think could maintain 50 extensions within the relative ease that we did, right? Just because we had intentionally made those decisions very early on and then also made it very easy to framework a plugin and bring it into our ecosystem. And investing in that, we did also invest a lot in getting outside of the WooCommerce sphere and learning from other ecosystems. Like, we work with Shopify really extensively and tried to see what we could bring into WooCommerce or what we could bring from Woo to that.
Launching Jilt, which was our email marketing app, I think was also really key to our success and the acquisition. And I think it would have led to much more improvement even long-term, how do we continue to operate the business independently? I will say that while selling in a marketplace and building on top of an existing platform is great, the shortcuts that you can take by doing that could hamper you in terms of wanting to run a much bigger business someday. So, what we learned from building Jilt in terms of how we went to market with a product outside of a marketplace and how we just nurtured the customer life cycle and how we built that as a platform in and of itself were really important lessons. And so, you know, one thing that you have to be mindful of is if you want to run a lifestyle business by yourself, like, yeah, build on top of another platform, that’s great. You’re going to have an awesome time doing that and you’re going to have a really fantastic life, like a lifestyle business. But we wanted to do something much bigger, and we also needed to kind of break out of that a little bit. And running a SaaS app at that scale was full of learnings that we would have never gotten any other way. I would have picked an easier segment than email marketing if I were doing it again, but yeah, we learned so much.
Patrick: Yeah, email marketing, well, yeah, that niche seems super advanced. There’s a lot of competitors in that space, and well-funded competitors, absolutely. Remind me what happened with Jilt? I feel like, did that project go? I remember seeing it around a long time ago.
Beka: Yeah, once we were acquired, we knew we wanted to bring a lot of the stuff we did into what we did inside of GoDaddy and to power other parts of the GoDaddy ecosystem. And when we were doing that, we knew that given its revenue, it could be profitable if we had pared back a team on it. We had been actively investing and trying to grow it really quickly. But given what we would invest in that versus what we were going to basically use for parts to kick-start other projects inside of GoDaddy, we felt like we weren’t doing right by customers by not investing in it in the long term. And so we decided to sunset it as a result and used a lot of the IP in other areas.
Patrick: Got it, love it. It’s actually good to know because I think some people at a very simplistic level say Jilt existed, it no longer exists, it’s a failure. That’s a very simple way of looking at it. And I love that you can use the parts for something bigger and there’s a difference between this could make a hundred thousand dollars a year and pay for one person’s salary, or how can you use the parts of this to make something that makes a million dollars a year and support a team?
Beka: Yeah, and when the reality is when you join a much bigger company, the financials change. And so what made really great sense as a small company isn’t going to be a force multiplier for GoDaddy’s bottom line. So once we knew that we weren’t going to develop it at the same pace we had, we felt like we weren’t going to do right by customers. And at that point, you make the very difficult and painful decision. Hey, if we are not exactly going to invest in this, then let’s give people a reasonable amount of time. I think it was over a year to keep using the product, but then say, hey, look, you need to be on something that’s going to be actively maintained and developed to grow your business.
Patrick: I feel like that’s an underrepresented skill, is knowing when to quit things, and I mean that in a good way. Seth Godin talks about this in his book “The Dip,” like, hey look, this is just not going to get us where we need to go, and we’re going to have to shut and give people lead time, give people advance notice. But rather than saying, well, let’s just ride this till it bottoms, let’s just keep the servers running and keep trying to take—I don’t say take advantage of it, but still trying to get a little bit of money from it—just shut it down because it lets your focus go in other places. That seems to be a secret skill of Sky Verge.
Beka: I guess that’s a fair point, is that we maybe took it for granted, but that ability to focus was kind of encoded in our DNA. We always, I think as a company operationally, did a very good job of allowing the team around, like, here’s the target we’re going after right now, here’s the annual objective, here’s the quarterly objectives that are going to feed this, and here’s how every single one of you is going to contribute to that. And like, now let’s all just go run toward it in parallel. It was, I think, a reason that our team was able to accomplish a lot with a relatively small number of people. And so that focus, I don’t think it necessarily registered on a conscious level for us the same way, but we knew that that was kind of something that was just always sort of encoded in how you work.
Patrick: Yep, love it. So I have two questions left here. So, the WooCommerce marketplace has changed a lot. Is there anything that we haven’t covered yet? And were there any changes to the WooCommerce marketplace that we haven’t talked about and how that may have affected Sky Verge and your decision making?
Beka: I think the breakdown of the exclusivity requirements is huge for developers. So, I’d say that now that you can sell in that marketplace and others, it drastically de-risks some of those brand and customer relationship things that I was talking about, right? Because the one challenging thing in a marketplace is if you don’t have that ability to nurture the customer relationship with your product and like get onboarding feedback and understand where pain points are and like just get that feedback loop that helps you build good products, it’s really, really difficult to keep doing that over time. And you become very reactive to support people who are unhappy but not always understanding the people who are happy and how they’re using your products. Yes, so I’d say that that change is huge. And I think if I were a developer today, I would try to take advantage of it even if I don’t get a lot of direct sales, just because building that marketing muscle and your customer acquisition is going to be important to your long-term success. The other thing I would say is it would be harder to stand out now as a result of a lot more people selling in that marketplace. And so, probably applies if you’re in Code Canyon or a different marketplace too, that’s where I would say brand and interoperability can be a big leg up there. And fostering that is a really important way to stand out in the marketplace.
Patrick: Love it. So for any developers who are listening to this, any engineers, do you have any advice that you’d like to give them on what to consider before starting a business built on another plugin?
Beka: The biggest thing would be understanding the tech risks of doing so, which I think we’ve covered pretty well, right? You’re going to have more dependencies, you’re going to be making commitments to working with other parts of an ecosystem because you’re all building on the same thing, more so than WordPress just because of how diffuse WordPress, in general, is, right? But once you niche down into WooCommerce or LMS plugins or something else, there’s that level of interoperability that’s going to be an implicit assumption from your customers. But yeah, knowing that risk is a big thing, and then understanding that you contributing to that ecosystem is going to be important to your success, just as you can contribute to your own products and growing them will be. And I think it’s something that’s maybe a non-obvious takeaway, is that you can contribute to growing the ecosystem and have a much bigger impact on your bottom line, even though it doesn’t feel as direct.
Patrick: Got it! I like it. Well, Becca, that takes us to the end. So thank you so much for being on the show. We really appreciate it.
Beka: Yeah, thank you so much. It was fun to catch up, and especially Patrick, our long history in the whole space, is always fun to kind of pull into some very old conversations back to the forefront.
Patrick: Absolutely! And thanks to all of you listeners for joining us on the plugin.fm podcast, where we sit down with inspirational makers who share their unique stories and actual tips and strategies to help you launch and grow your software product business. If you enjoyed this episode, hit subscribe to turn the YouTube algorithm in our favor so we can keep making awesome content for you. I love doing this stuff. If you’re on plugin.fm’s website, go ahead and smash the subscribe button to get early bird access to future content or amplify the episode on social media so we can help entrepreneurs like you in their journeys too. plugin.fm is brought to you by Freemius, your all-in-one e-commerce partner for selling software plugins, themes, and software as a service. If you’re struggling to grow your plugin revenue, send a note to [email protected] to get advice from Freemius’ monetization experts. Thank you so much, everyone, and have a great day! Bye.
