Starting with a productized service and building a 7-figure product around
it
Craig Hewitt built a productized service with an email list. Then, he built a SaaS product called Castos and combined it with the productized service.
Over time, his SaaS product started bringing in more and more revenue. And now, it's making 80% of his 7-figure ARR.
Here's Craig on how he started with services and built from there. 👇
Starting with services
I started the precursor to Castos — a productized service called Podcast Motor — after my second child was born as a way to kind of escape the corporate rat race. And it's kind of grown and evolved from there.
Next, came an acquisition. We were doing done-for-you podcast editing and production and one of our customers from Podcast Motor came and said, "Hey, I have a friend who has this WordPress plugin in the podcasting space that they're looking to sell."
So we met with the person and agreed to buy the plugin from them. At the time, the plugin was entirely free. It still is and always will be. The plugin is called Seriously Simple Podcasting.
Finally, we built Castos as an integration into WordPress for people who wanted to do podcasting. .
There were already other people doing a similar thing, so it was already validated — and none of them were doing it very well from a product perspective.
Starting with bootstrapping
Initial product development took about four months. We connected with our first developer through a recommendation from the person we bought the WordPress plugin from, and that turned out to be a really good fit. I'm a single non-technical founder, so learning how to communicate product vision to a developer was a big challenge and learning curve for me.
He built it with Laravel, MySQL, at the time Bootstrap, and now Tailwind. From a technical perspective, we have a reasonably complex product, especially on the analytics side. We adopted ClickHouse as a data storage mechanism for our analytics a couple of years ago, and it's really been great in terms of us being able to scale effortlessly without a lot of capital expenditure.
We were entirely bootstrapped for about a year. The productized services fueled the investment and growth.
The beautiful thing about running a productized service is, if you have the team and the systems done right, then it doesn't really require a lot of your time. I had already quit my day job and Podcast Motor service was sustaining me. So I didn't need to do any kind of extra side hustle work or anything like that. It's a really good model for other folks looking to get into this.
Over time, the mix of productized service and SaaS has shifted to where now the SaaS revenue is about 80 percent of our total income.
Seven figures
These days, our flagship product is our hosting platform — it's CMS of sorts. Podcasters come to us to publish their content to Apple Podcasts and Spotify. They get a beautiful-looking website for their show, as well as analytics about their listeners and what content is performing best.
Then, we have a suite of monetization tools that let podcasters make money from their content. And yeah, folks really seem to love it. We're very fortunate to have such a strong degree of product-market fit.
Today, we're well beyond the 7-figure ARR mark.
Launching to a pre-built list
Our launch was actually sort of straightforward. We had built an email list at PodcastMotor through a bunch of content marketing, so we launched to them.
And we launched an update of our free Seriously Simple Podcasting plugin that included the hosting integration functionality. Specifically, within WordPress, we have several contextual calls to action within the plugin to show the value that a free user would get from upgrading to the paid hosting plan, like advanced analytics, better website performance from offloading files, storage and distribution from your web server, monetization options now. And that was the majority of how our free users of the plugin found the paid hosting solution and signed up.
From there, we continued our content marketing, mostly in the form of SEO and blog writing. We did that for years until slowing down recently due to what AI is doing to SEO.
We were very fortunate to have paying customers on day one and for a long time have acquired customers relatively on autopilot, both from content marketing and SEO and from our integration with WordPress.
Solve expensive problems
My biggest piece of advice for indie hackers looking to get started is this: Solve expensive problems.
It's easy and appealing to try to solve small niche problems to your fellow developer audience or other indie hackers. And I think anyone who's done that will tell you that it's largely a trap, that building a seven or eight-figure business at $19/mo is really hard.
You just need so many customers. The top of funnel has to be so big. Churn has to be so low and everything needs to be just really buttoned up. I mean, we have thousands of customers at Castos, and that's a lot of moving parts compared to serving 200 customers at $500/mo.
So the lesson I've learned is to charge more or find an industry where you can charge more so that you can scale more effortlessly.
Keep learning
It's a little meta to be in the podcasting space and talk about learning resources, but podcasting and podcast consumption is really how I got into this business. I just listened to a ton of podcasts like Pat Flynn and Smart Passive Income, Rob Walling and Startups for the Rest of Us, Dan and Ian at Tropical MBA.
These days I learn mostly through reading and YouTube. YouTube is just an amazing place and probably will continue to be the number one learning resource for most of the world for modern things.
And I read a ton of business books, a ton of biographies, and a ton of self-help and personal development books. The list is long. I read dozens of books a year.
Follow along
You can follow along on X, YouTube, and my personal website. And check out Castos!
Leave a Comment
Hot take: Most indie hackers are addicted to building products nobody wants because services feel "beneath them" - but Craig just proved that washing dishes (services) teaches you more about running a restaurant than reading cookbooks (building SaaS in isolation) ever will. The real controversy isn't whether to start with services, it's admitting that your brilliant SaaS idea probably sucks without real customer validation first.
Craig's story is amazing, but even for the ones who are not able to do a 7 figure ARR, if you go the service way you atleast have something to pay the bills with.
Really cool to see how Craig started with a service, built an email list, and turned it into a successful SaaS. Love the “solve expensive problems” advice — so true!
hey Ihar, thanks for the message, and yeah for sure, solving expensive problems makes almost everything easier in a business. Glad this writeup was helpful.
It's funny how more than a decade later Youtube is still one of the best if not the best platform to learn stuff.
sure right about that...do you run your YouTube channel there on it
Nope. Just a thought
I’ve made the same mistake of chasing small problems before, totally agree that solving bigger ones is the real game changer. Appreciate you sharing this 🙏.
I hope I can be that amazing, too.
why you will be
if you do nothing nothing will happen. what online or digital business are you into?
it begins with you dude
amazing bro
no story no glory. He has a story therefore his glory
This is awesome! great read!
awesome yeah
Like how you started lean with a service and let real customer needs shape the product. More Indie Hackers should take this route instead of guessing their way to product–market fit.
What was the key signal that told you it was time to build the full product?
The core idea here is starting with a service and using it to fund a product. Most people want to skip to SaaS without touching reality first.
“Solve expensive problems” also hits. It’s tempting to build tools for other indie devs, but unless the pain is deep or the customer has real budget, it's a grind.
This is a solid reminder that boring, painful, and repeated problems usually point to real opportunity whether it’s a service or a product.
Loved this breakdown. This exact model — service → product — is the same path many of our early users are on.
I’m building CompliAssistant to solve one of the hidden but expensive problems founders often overlook early: GDPR, HIPAA, and AI policy compliance.
As services scale or shift into SaaS, these legal/data issues often sneak up. We’re making it simple for small teams to stay compliant without hiring legal help.
Craig’s journey is gold — and a reminder that smart systems (not just code) are what scale.
thanks for the post , really ispirational
Thanks for sharing, I hope to build a top tier product like yours someday 😅
Most of the AI based startups are just a nice ui wrapped with openAI or claude api.
Most of the people talk about building in public and succeeding but nobody talks failing in public.
The failure rate is more than 90% but still nobody talks.
Really insightful read! Starting with a productized service can be a smart way to validate demand and build steady cash flow before scaling into a full product. One thing I’ve noticed working on mobile apps is how important it is to maintain strong feedback loops during that transition — ensuring the product truly solves core user problems and adapts as needs evolve.
Also, balancing feature development with user experience is critical. It’s easy to get caught up adding functionalities, but simplicity often drives better retention and satisfaction, especially in mobile contexts.
Curious how you managed prioritization and user testing as you scaled from service to product?
Fascinating case study! The transition from service to SaaS mirrors what we're seeing in B2B procurement tech. Three key takeaways:
Service Data Fuels AI
Like how podcast editing revealed hosting needs, processing millions of procurement requests trains AI to decode vague requirements (e.g. "EU-certified heat-resistant parts") into perfect supplier matches.
Platforms Beat Point Solutions
The WordPress integration lesson applies perfectly: Modern procurement tools win by becoming the system of record - unifying supplier discovery, RFQ management, and payments in one workflow.
Predictive > Reactive
Just as Castos evolved to analytics, next-gen procurement platforms will predict price fluctuations and supply chain risks using historical data patterns.
Discussion sparks:
• Where should AI stop in procurement? Complex categories still need human nuance?
• For global platforms: Go wide with multi-language support or deep on local compliance first?
It's amazing to see such growth!
It's amazing!
The article is very informative and I myself, by the way, learned a lot on YouTube. Previously, it seemed to me that I needed to buy some expensive courses, but then I began to learn all the intricacies of running a business myself and it worked.
Building trust begins with a productized service that validates market demand, streamlines delivery, and streamlines the delivery process. A focus on repeatable value and growth enabled James Fleischmann to scale this model into a seven-figure business.
This is awesome — what tech stack did you use
This is awesome — what tech stack did you use?
Love the inspiring story--- curious how you validated demand?
Really liked this! I’m building Trend, where people predict markets and build a public rep.
We’re also starting small with milestone-based tasks before going full product.
Curious: when did you know it was time to move from service to product?
Solid story, thanks for the share
Bootstrapping with a productized service is such a smart move. I’ve done the same at Brokr Agency - we help founders avoid hiring the wrong marketing teams by vetting and managing agencies on their behalf. Starting lean gave us the space to refine the offer and fund growth without rushing.
Also +1 to solving expensive problems. Hard truth a lot of folks overlook. 👏
indeed
Love this breakdown, Craig. Really cool how you used a service business as a springboard — not just for funding but for insight into what people actually needed.
Curious — if you were starting today, would you still begin with a productized service or go straight into building SaaS?
在電子煙產業，評論員扮演著至關重要的角色。它們不僅為消費者提供了有價值的參考，也有助於提高產業內的產品品質。身為電子煙評測人員，評估一款POD設備需要進行多維度的分析，為使用者提供詳細的信息，幫助使用者評估產品是否滿足自己的需求。以下是評估電子煙POD設備時需要關注的主要面向：
外觀與設計：第一印象的重要性
當使用者第一次接觸，視覺和觸覺的印象直接影響他們的購買意願。設計精良的電子煙設備可以吸引更多潛在用戶，同時提升整體體驗。審查時，請考慮以下細節：
外殼材質： 注意設備外部的材質與設計。這些因素決定了產品的質地和耐用性。
尺寸和重量： 設備的尺寸和重量決定了其便攜性。 60g左右的設備一般比較適合日常使用，過重的設備可能會影響使用者體驗。人體工學也發揮著至關重要的作用，因為圓角更適合長時間使用。
Pod 更換： 卡扣式和磁性連接更方便，而螺紋設計更穩定可靠。特別值得關注的是煙彈介面的防漏設計，這也是業界持續技術升級的重點領域。
煙彈和線圈性能：技術的核心
煙彈和線圈是POD的核心部件，它們的性能直接決定了煙霧的口感、煙霧量以及整體的用戶體驗。審查時，應深入研究以下幾個方面：
Pod 容量： Pod 容量通常在 1.5ml 到 3ml 之間。測試時記錄pod的實際使用時間，以評估是否能滿足日常使用需求。
線圈類型： 市面上常見的線圈類型有陶瓷線圈、棉線圈等：
陶瓷線圈： 陶瓷線圈以「無焦味、耐用」著稱，深受市場青睞。
棉線圈： 傳統設計，價格較實惠，但使用壽命可能較短。
功率調節和阻力： 支援功率調節的煙彈為使用者提供更豐富的吸煙體驗。線圈的電阻會影響加熱速度和味道。低阻力適合產生大量蒸汽，而高阻力則適合產生更精緻的味道。例如，水果味的電子液體通常新鮮而甜美，更適合高電阻線圈和低功率輸出，以避免過度濃鬱或燒焦的味道。
模式切換： 該設備是否同時支援 MTL（口到肺）和 DTL（直接到肺）模式？一些設備允許透過更換線圈在兩種模式之間切換。
電池壽命和充電性能：日常使用保證
電池壽命和充電性能直接影響設備的實用性，尤其是對於重度使用者而言。電池性能是一個需要考慮的關鍵因素。
電池容量： 例如，800mAh 的電池可能足以滿足輕度使用者的需要，但重度使用者可能需要容量為 1000mAh 或更高的電池。 評測需要記錄設備在不同使用強度下的實際續航表現。
快速充電支援和電池指示器： 設備是否支援快速充電以及是否有電池指示器會顯著影響使用者體驗。
Craig's journey is inspiring! Starting with Podcast Motor, a service, allowed him to bootstrap and understand customer needs intimately. This led to acquiring a WordPress plugin and eventually building Castos. It reminds me of the early days of Papa's Pizzeria, where understanding customer orders and building a solid foundation were key. His success proves that solving expensive problems for a pre-built list can lead to seven-figure ARR. Keep learning and building!
Craig Hewitt's journey from building a productized service to creating a successful SaaS product with Castos is truly inspirational. His emphasis on solving expensive problems and focusing on charging more to scale effortlessly is valuable advice for all indie hackers. It's amazing to see how he leveraged his email list and skillfully integrated his services to grow his business to a 7-figure ARR. Congrats on the success, Craig!