How to acquire a SaaS to boost your existing business – with Craig Hewitt from Castos
How has Craig vetted and acquired a SaaS company as a non-technical founder? How has he embedded it within his existing productized service business? And what is the ShapeUp development methodology which he uses within his remote team?
Find out on today’s show! Listen to the episode or read the transcript below.
Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, development, remote work, and everything else non-technical as well as technical. Founders need to know to launch and scale software products. Today’s guest is Craig Hewitt, founder of Podcast Motor, which has just merged with his podcast hosting platform Castos. Craig, welcome to the show. Great to have you.
Hey, Victor. Thanks for having me.
Craig, so, you’re a non-technical founder. Is that right?
That’s right. Yep.
And so how have you ended up running a very successful SaaS business?
Yeah, so I’d like to say I kind of backed into running a SaaS business so like my first foray into a kind of online business, as you mentioned, was Podcast Motor. So, a product I service that does podcast editing and production, and ran that for about four or five years. And in the course of that one of our podcast motor customers actually introduced me to a fella named Hugh Lashbrooke, who was the kind of original creator of the Seriously Simple Podcasting WordPress plugin. He had taken a job at automatic and wanted to sell the plugin to someone who would take good care of it. And so, we bought the plugin and built the Castos platform, kind of on top of that, so we have a freemium model that Castos where the WordPress plugin is free, anybody can use it to host their and host their podcast files, wherever one of the options to host your files is with casters, and it’s really tightly integrated there to make kind of managing your podcast from WordPress, really easy.
And at the same time, you’re still running your product I service which allows people done for you editing of your podcast shows is that right?
Yep, that’s exactly right.
Perfect. How did you go about vetting that plugin, so you’re being made aware by referral of a great WordPress plugin out there, you could buy, it fits your business, it fits your customer base, you can acquire more customers through it? What did you do? How did you decide to actually buy it?
Yeah, so I think reflecting on it now; like a big part of it was the person that introduced me, Brad Touesnard from Delicious Brains. So, folks in the WordPress world probably know of Brad and their business. And he’s just a really high quality, really good person in that space. So, like him saying, “Hey, you probably ought to check this out” was a big nod and kind of vote of confidence. And then from there probably didn’t do as much due diligence I should have but the plugin had a lot of good reviews and wordpress.org. So that kind of social proof. And maybe other folks doing some due diligence for me, was part of that nine, install the plugin and gave it a whirl and it worked great, and kind of just went from there.
Wonderful. And so fast forward to today, basically, what’s your company setup now? What’s your team size? How many people do you have on board?
Yeah, so we’re eight people full time now. Three developers, and I’m kind of the product lead, person that aggregates a lot of feedback from different places. You know, we have a product feedback board where customers and people using the plugin can go and suggest and upvote things. We obviously have like support channels that give input into the product; I have things that I want to build. So that’s what the product team looks like.
Wonderful. Are you guys in an office or you are remote? How does that look?
Yeah, we’ve always been remote.
Where are you based? Where’s your team based?
So, I live in France, so about 30 kilometers south of Geneva. And then we have folks a bit all over. So, we have developer in Montenegro. We have a developer in Cape Town, South Africa, we have our third developers in upstate New York. And then Success and Support and marketing are all kind of on the east coast in the US.
Did you even decide for geography or was that all based on the people who applied?
Yeah, it’s all based on the people. It’s all based on the people. But I like that we have kind of buckets. We have this kind of European time zone bucket. So, myself, and our two developers here are on the same time zone. And then in the US, they’re all in the same time zone. I think that kind of congruency is important, even if you’re not all in the same time zone for groups of you to be in the same time zone makes it a lot easier to communicate synchronously.
Is there any time zone that would have been too far or wouldn’t that better?
Yeah, I think especially early on in a business where you’re not as organized and not as good at documenting and have processes around things that like, for us, you know, someone living in the West Coast, or some places in Asia, probably where it would be 789 hours difference for me is just too much because like, I have family and kids, and I don’t want to be working eight o’clock at night all the time. And I don’t want to ask people to do the same thing.
So even if people are well; somewhat close to you, but then further apart from each other, so to speak, people left and right, geographically more east more to the west, you end up being a bit of a micromanager or a bridge in between people. How’s that working?
Yeah, I try very hard not to be. And I think that that’s an easy trap for people to fall into. Maybe even more so for non-technical founders, because we don’t understand a lot of what is going on. And we feel like we need to understand and have our hands on a bunch of things to have the confidence that everything is going in the right direction. And it’s something I’ve worked a lot on to say like, “I don’t need to be involved in every conversation, I needed to enable the leaders in our company to own the process and the outcome of the things that we’re doing”. And it’s a continuum; where maybe a third of the way there but yeah, we’re getting better at it.
And how did you find your first and the subsequent developers. You have three, you said?
Yeah, so Jonathan Bossinger, our first and lead developer was a recommendation from Hugh, the fella that built the plugin, they know each other, they’re both in Cape Town. So, Jonathan was just recommendation, and that’s worked out brilliantly. Danilo our second developer, we started, we hired him from Upwork. And kind of started on a project basis, we wanted to build like this admin panel. So that was a really kind of concise, boxed piece of functionality that we wanted to build. And it was a nice way to kind of start on a trial with somebody on not full time at all.
So, both from like a risk perspective, and a financial perspective was easier. And then our third developer who hired about three months ago; placed an ad and we work remotely. And that’s where he came from. And that process was intended for him to be, you know, to come from outside of our kind of sphere. And to be a full time hire right off the bat.
Did you also do a concise test project with him or not anymore?
Yeah. So, our process that we did with him with our latest hire, we really like and we’re running it again, now we’re hiring a fourth developer. And we’re doing test projects. And now even we’re doing them as like the first step after the application. So, we have the application and people fill it in, I kind of filter and then pick the people that I think have really good potential, and then send them a test project; we have test project for Laravel, we have test project for WordPress, depending on where someone’s background is. And that’s really the first way they interact with us. And it should take a couple of hours for somebody to do. And the goal there is really to get kind of the hard data on how somebody works, what their code looks like, how well it’s documented, what their commit messages are, and how often they commit all these kinds of work and workflow things around some a developer because like writing code, as I’m coming to learn is like just a piece of it, but how they communicate and how they work with the rest of the team is super important. We’re parsing that out earlier now.
What else have you learned over the past years working with developer’s day in day out?
Yeah, a lot. I mean, it’s been a huge progression from with Jonathan. Starting out, literally, we had just this enormous Google Doc, and a bunch of chats and Slack. And I think that’s not wrong, when you’re just starting out. Like I think people definitely can over-optimize a development process. But as we got a second person, that definitely broke a lot of how we worked. And now we have a third person that’s in a different time zone.
And so that’s broken a lot of how we work. But the biggest thing has been because I’m not by nature, a really organized person, the biggest thing has been to be very clear about what I want to build. So that they can go and kind of implement it successfully on their end, because otherwise, like I’m ambiguous, I say, just like a one liner, it’s like, hey, let’s go build a login page, or an admin panel. And they go build it. And they make a bunch of assumptions that when they come back and say, “Hey, it’s done, you can test it”. I say, “This is wrong, this is wrong, this is wrong, this button’s wrong color”. And that’s just like; they end up doing twice as much work. So, we’ve done a lot around kind of our product process and how I take what’s in my head and put it in a quote on paper for them to be able to go and run with.
So, what was your biggest win here in that process, what addition did you make to your product process that made the biggest impact on clarity?
Yeah, I think the single biggest thing has been working with a designer, because they are able to literally help me take what’s in my mind and put it in something that developers can see and understand. So, Francoise, our designer, and I talked through, you know, just like in a zoom call, what I want to build, he asked a bunch of really good questions about UX, and kind of technical considerations. And then he goes and builds the mock ups and prototypes and Figma. And then the developers then can take that and say, totally understand, like, this is what this is, and this is how this interacts, and they can go build it and get us a lot closer to quote right the first time.
And at the same time, just as you said, you can also overdo documentation, you can overdo detailed descriptions. I know that from a lot of especially technical product managers who even try to do some of the developers’ job and defining data structures defining pages of acceptance criteria, what can or cannot go into a form field. And that’s probably right, in a lot of points, but maybe not in a very lean startup environment. So, you’ve said to me before, “That you’re trying to follow something that’s called the shape up methodology”. Can you give a super quick overview over what that is and where it’s coming from?
Yeah, so shape up is a book by the folks at Basecamp, that talks about kind of how they do a product process. And part of it is from a kind of timing perspective, they work in kind of eight-week buckets, where six weeks of that is on where they’re actively developing things. And two weeks of it is off, where developers have some downtime and time to focus on refactoring, doing tests, updating, libraries, things like that. You know, like we say, they’re not really moving the prod product and project forward, specifically, but that they allow the developers to then go be successful and focus on building features and squashing bugs in those on cycles.
So yeah, we’re six weeks on two weeks off, roughly, here, like at the end of the year, that that gets extended a little bit to accommodate just regular calendar stuff. But the idea really, is that you don’t define too strictly what you want to build right at the beginning, but you kind of shake it up. It is like a ball of Plato, you put it into a ball, and then you do a little bit of molding on it and take a look and say, is this really what I want? You might go back, but you try to as loosely as you can define what you want. And then ask a lot of questions about like, Am I really trying to make a ball or am I trying to make a a box, right? And kind of asking yourself a lot of questions about specifically what am I trying to build and it is kind of this path we’re going down getting us there is another. Is there another more creative or minimalistic path that we can take that achieves the same thing for the customer.
So essentially, it’s about giving a lot of context, enough context, just enough constraints to get going. But then about molding it together with a developer with their feedback, trying to get something done, and review that quickly. Right. So, we’ll definitely link up more about shape up as well, in the show notes. For concrete management, what do you use for managing issues and tickets?
Yes, we use notion for almost everything. We use GitHub for actual bug issues, but are kind of proactive Project Management stuff is all in Notion.
Wonderful. Do you also work in like sprints or is it more of a Kanban board or how is your setup here?
Yeah, so, each cycle, whether it’s like an on or an off cycle, it has its own board. And in that board, there’s like four or five columns. One of them is our backlog. So that’s where everything goes, everything we want to build, every idea we have goes in there. And then as we’re kind of starting a new cycle, we have kind of all hands team call to discuss what we’re going to have? What’s going to be included in that cycle, either an on or an off cycle. And we kind of pull things from the backlog into the pending columns, and then there’s pending and active and testing and reviewed and then deployed. So that’s how we manage it. And then at the end of the cycle, all of the leftover stuff in the backlog gets pulled to the next cycle so that we don’t forget it.
So you mentioned this backlog, where you have everything you put in there all the ideas you have probably things that come from customers. How do you prioritize that, all these requests are your own ideas?
Yeah, I mean, it’s like the epitome of compromise, right? It’s like, there are things that I think you have like from a business perspective, you have to say, “This is getting prioritized because the business needs this, we need this to be competitive or gain a competitive advantage”. And then there are things like, this is an edge case bug, or this could be optimized. And for me, as a non-technical person, this includes things like updating our Laravel version, updating our PHP version, which, like before, I would have said, this is just wasted time. And now I’m understanding. Okay, this is important for us to continue to move fast in the future. And I would put things like writing tests in there that like, we need to go back and refactor this thing and write a bunch of tests for it. That has to be allocated in an “On” or an “Off” cycle. Because it just helps us be successful going forward.
Have you always been writing tests? Are these automated?
Yeah, we’ve definitely not always been writing tests, we started about…. Gosh, maybe a year and a half ago. So, for definitely, a year and a half. We had no tests. And that was a mistake. Right? But we didn’t know. I didn’t know. And, you know, the developer didn’t know. So, if I had it to do over again, I would definitely write tests from the beginning, because I know it makes you go faster and with more confidence as the app gets bigger. But yeah, basically, now our policy kind of is; if you’re touching a piece of code that doesn’t have tests, it’s your responsibility to write tests for it. But we didn’t kind of go back and write tests for the whole product all at once.
Nice. And what are the next steps for forecast those what’s on your roadmap, if there’s anything you can or want to publicly share?
Yeah. So, I think that in the podcasting space, the big kind of trend and movement that we’re really excited about is around private podcasting. So, this idea that as opposed to this podcast, which you want everyone to listen to, there are a lot of scenarios for people to say. I only want specific people to have access to this podcast. And just a couple of examples for folks to think about is like you run a membership site, or you run a course, and you want to offer a podcast to those members or those students. And then increasingly…. You know, I’m a large organization, I want to have a podcast just for my employees on this team. And so, things like HR and corporate like C-Suite messaging sales teams are adopting internal company podcast and we have a lot of really cool tech around that. And so, a lot of interest and a lot of focus for us around private podcasting, and even paid access to private podcasts that we’re getting into.
That’s super exciting. Where can people learn more about Castos and yourself?
Yeah, so castos.com. C-A-S-T-O-S dot com is the place to go. And for myself, you want to reach out. I’m at craighewitt.me, where I blog very occasionally, but you feel free to reach out, I’d love to chat.
Thank you so much for being on the show.