Today, I want to share with you something rather unexpected. I’m building a Software-as-a-service business again. You heard that right. After a few years of writing for people, I’m coding for machines again. And this time, I’ll share the whole journey, starting today, right from the beginning.
Let’s build in public.
Now, I’ve been a software engineer for decades. Coding was always an option for me. But over the last three years, since selling our SaaS business Feedback Panda in 2019, I’ve focused more on writing and building a media business around my knowledge as a founder, developer, and creator. It’s been enjoyable to shift my focus on education, especially through interviewing people on my podcast. That alone has made it all worth it: getting to know people, learning from them, AND sharing all that with the world? Couldn’t imagine a more rewarding experience.
However, recently, I’ve felt the itch to code again. I mean, I’ve always felt it a little, but I never had a reason to dive back into it.
But the more I saw the developments in the software space, the more I got excited. With AI tools now available to everyone, not just big companies, diving back into coding has been exciting. ChatGPT, GitHub Copilot, Meta’s Llama, and now Google’s Gemini? Every day brings new tools and products to the market.
Experience this article as a podcast or as a newsletter:
And that is the kindling under the entrepreneurial fire.
I’ve built software businesses around problems I understood and experienced in the past. That’s always been my approach: find challenges in the communities I was already in. One such business is PermanentLink, which creates permanent links for authors to use books to always work, linking to the intended site or an archived version. That’s a problem I personally had and found a lot of other writers struggling with.
Finding problems you understand because you’ve faced similar challenges is a great way to build a business. So now, I’m working on another SaaS business because of exactly that. The big reveal: I’ve spent the last week or two building a prototype for something called Podline.fm.
Podline provides voice messaging services to creators, podcasters, and those running audio-centric businesses. Because that’s exactly what I do and understand.
If you want to have audio-centric conversations with listeners, viewers, customers, or peers, the tools in the market are pretty limited. Many podcasts that want their listeners to send in messages have resorted to asking their listeners to “record a voice memo and email that over.”
Now, there’s a saying in SaaS that whenever a spreadsheet is emailed between professionals, that’s a software business waiting to happen. I think this includes having audio messages recorded, emailed, and then painfully organized in some email client.
And that’s what I need. I toyed with asking for listener questions before, but the tools were horrible, and I couldn’t manage the many submissions I got. Now that my podcast audience is in the 5 figures, regular tools won’t cut it, and that’s where Podline comes in.
It’s a podcaster tool that helps manage and use audio from audience call-ins. This isn’t an original idea, by the way. I’ve seen similar solutions online, like on Seth Godin’s Akimbo podcast, where listeners send in questions, and he answers them on the show. This format is popular for shows that involve their community heavily.
However, the quality of these calls often feels like someone was calling in from a phone or talking through a potato, not using a high-quality microphone. I want better quality for myself and other podcasters struggling with listener voicemail reception.
That’s my market. Podcasts with an existing audience that is already willing to call in questions, feedback, comments, and lots more. I’m building a collection and management system for professional and serious content creators.
Do they have a budget? They sure do: thousands of podcasts are using even the not-so-great existing tools. I know this because I looked up my main competitors and ran competitor research reports through builtwith.com, a tool that scrapes the internet and checks out which tech stacks and tools it can infer from the HTML of landing pages and applications. These reports were not cheap; the monthly plan for BuiltWith is just under $400, but the list of websites, emails, and estimated tech budgets for the companies using the current solution is both incredibly useful and very motivating. Money flows already.
All I need to do is to actually build the thing.
And that is what got me incredibly excited. Because coding, as I knew it from 2019, has changed completely.
We now live in the age of AI, and I was skeptical as a traditional software engineer. I know how to code, so why would I need a machine’s help? But I’m glad I gave it a shot. Over the last week, I’ve had several moments where I just laughed out loud at how efficient the Google CoPilot integration in my editor is. Several times, I stared in disbelief at the suggestions it made, which were exactly what I was planning to code up next.
It can be jarring to see a language model understand your codebase better than yourself. But it’s incredibly helpful.
That’s the coding side. I also found AI incredibly helpful for debugging. A few dozen times now, I have thrown error messages and the corresponding code directly into ChatGPT 4 and, until now, at least, have always gotten a correct (or mostly correct) answer back.
It has increased my development speed by at least 5x.
And it’s not a tiny project: I’m building a product that makes capturing high-quality audio easier and helps podcasts with millions of listeners manage their data reliably.
The idea is to create a reliable voicemail system for podcasts with lots of incoming messages.
So, let’s talk tech.
Over the past week or so, I’ve been working on a prototype. As expected, it’s been technically challenging. Not the SaaS part, really. I got some experience there. But the recording part has been more complicated than I thought. Capturing audio can be difficult due to different browsers and their implementation of the web audio API. Some browsers are extremely protective of the user’s microphone, while others make this very easy. And then there are different audio formats, some of which work in Chrome and not Safari, and the other way around.
Storing the audio in a high-quality format is also tough because you can’t use small MP3 files; you have to deal with large amounts of data and server-side audio encoding. Which is something I’ve never done before. The kinds of data I had to work with were mostly text, maybe a few images here or there. But with audio, file size explodes, and resource consumption does too.
The goal is to make this product unique by improving both the capturing process and the backend management for podcasts. So that’s the plan: build a voicemail system that enhances audio quality and makes managing call-ins easier for podcasters everywhere!
I want to innovate on two levels here: sound quality and ease of message management because those are the main pain points I hear about in the grapevine of the podcaster community.
So, I am diving heavily into backend processing. I am fortunate to live with (and, incidentally, have built a prior business with) a professional audio engineer. So that’s where we’ll tackle the audio quality features. This is something I’ll get to over the next few weeks.
But here’s what I already started with and have found —to my absolute surprise— to work extremely well already: transcription and summarization.
When it comes to managing audio data, having its content as searchable text and understanding what it’s about at a glance is something that is direly lacking in the voice messaging space.
So, I used what I have learned about GPU-based language models in the past. Much to my initial surprise, you don’t need a GPU to run them on your computer at all! I’ve been using CPU-based fast transcribers for my podcast for months. And since that’s all command line stuff, I know that if it can run on my laptop, I can have it on the server.
Which is precisely what I did, and it took me less than an hour.
I created a server-side service using OpenAI’s Whisper for transcription (or rather, its whisper.cpp implementation, which allows for CPU-only inference of something that used to need a graphics chip) and another service for summarization. This service provides a one or two-sentence summary of any messages that arrive on the server. The goal is that when my notification email reaches its recipient, it will already contain the audio and its transcribed and summarized content.
I thought I’d need to use the ChatGPT API for this. You know, the regular web application way: whenever I had a transcript, I’d send it to OpenAI, they’d summarize, charge me a fraction of a cent, and I’d get to use the results.
But this SaaS project was supposed to be as dependency-free as possible from the start. I’m a huge fan of platform de-risking, and I wanted to actively avoid building a core service feature to work exclusively with another API.
Fortunately, open-source software is an amazing thing, and I found something during my implementation of Whisper for transcription that made me perk up. The maintainer of the whisper-cpp tool was also the maintainer of llama.cpp. And that is precisely what I needed.
LlaMa is a collection of open and free-to-use language models initially provided by Meta, aiming to outperform OpenAI’s GPT models. They’re trained with between 7B and over 100B parameters, which impacts the memory and execution time footprint of these models and their file size. Add quantization to the mix, and you have a complicated AI system that you can run reliably on your computer.
This was mind-blowing to me: a year ago, I wouldn’t even consider ever running something like this on a MacBook Air. But with llama.cpp, I had an OpenLLaMa model up and running in under 30 minutes. And it was giving me ChatGPT-style answers to my prompts. That blew me away. Particularly because the laptop has 16GB of RAM, just like the server I spun up for Podline.
I had to work on getting the prompt right and ultimately experimented with a few different language models, but this was working within hours. What I had believed to be the most complicated part of the tech MVP was all done in a single afternoon. I even added a few nice-to-haves, like automatically figuring out the tone of a message and what kind of message —question, spam, feedback, complaint— it might be. All in one LLaMa query!
And with transcription and summarization figured out, I could dive into actually turning it into a service.
This brings us to the tech stack choice. For this project, I’m using the Laravel PHP framework, which opened my eyes to modern software engineering. Because I didn’t expect to ever find a framework this good.
That’s probably because I underestimated PHP. When I started coding, PHP was my first language. We’re talking PHP version 4. Back then, it was fun to build web applications that could be placed on a server without needing executables, which is why I got into PHP in the first place. But it was also clunky, under-tooled, and lacked a strong (or mature) community. So I moved on.
I’ve been part of the JavaScript community for a decade after that, witnessing its incredible growth. From jQuery making websites more interactive to the rise of frameworks like Angular, Vue, Svelte, and React, it’s been amazing. The thriving ecosystems and libraries they’ve inspired are impressive.
I also explored the Elixir programming language (because I was hired at a company that was using it), a functional language with a smaller but equally fascinating community. They focus on building high-performance software rather than always chasing new ideas, like in the JavaScript world. So, I got a first glimpse into a more mature and less argumentative community. My last several projects, including PermanentLink, have been built with that tech.
Then I discovered Laravel, which is the brainchild of Taylor Otwell (and many others.) Laravel has something unique I haven’t seen much in JavaScript or other communities. It has an ecosystem that funds the framework’s development and its core plugins. It’s pretty cool. Otwell hasn’t just created a great framework. He has also set up a business around it that is quite a sight to behold.
Laravel, for example, is open source. You can download, install, and use it however you want. But there are also extra tools Taylor and his team created that make it easy to do things like integrating Stripe for payments or monitoring your software with Laravel Pulse. These ecosystem tools, like Laravel Breeze or Jetstream to spin up a working email-based authentication with nifty features like 2-factor auth and teams, are mostly free and easy to use as plugins that automatically integrate into your system because they’re designed by the people who build the framework.
As a business owner and entrepreneur, I find the monetization side interesting. The Laravel team has built server management and deployment tools that work well with external resources like AWS, Hetzner servers, or DigitalOcean droplets. Laravel Forge and Envoyer make it easy to have reliable and fast deployment scripts ready to connect with your GitHub repositories.
You can pay a low monthly fee for a server orchestration system tailored to your applications.
And then there are also some software pieces that require a one-time license fee, like a full Stripe-based billing backend. Brilliant monetization of an open-source framework.
And, just to be clear, I’m not paid to say this. I’m just in awe of what can be built when technical skill meets business vision.
This approach to building a self-sustaining software ecosystem is fascinating. And it results in excellent tooling.
In just an hour or two, I had a complete framework with login features, user authentication systems, password reset options, and billing. It even has a team component where users can join or create teams within the software, all plug-and-play. It’s really cool how everything comes together so easily. Integrating Laravel Spark cost me $100. It’s a well-integrated billing system that connects with Stripe, easily updating and syncing. In just an hour or two, I set up the whole SaaS backend, which would have taken me weeks to figure out if I had built it myself.
And then I got to implementing the basics: messages, channels, widgets, landing pages — all the things needed for my voice messaging system. I figured out how to use Laravel backend processes, or queues, to use FFmpeg for audio conversion, how to call Whisper.cpp and llama.cpp to do the computation-heavy AI work, and how to pull it all together. I had to write my own audio capture component that supports high-quality WAV content, an audio player for my backend, and many smaller things.
Right now, I have a mostly working product. Messages can be recorded, transcribed, summarized, and can be listened to and downloaded from a backend. This is bizarre because it only took me a week of coding occasionally. Of course there are still things to implement, like email notifications, but that’s not going to be much of a challenge. Again, the tooling around Laravel is spectacular, and there are even local email testing tools to make this easier.
Here’s a quick word on the economics of this business right now. Hosting costs me around $20 a month on the Hetzner cloud, Amazon Webservices S3 is around $1 but will scale with more data saved, the deployment toolchain is $30 altogether, the domain is $20 a year, email hosting is also around $20 a month, and everything else (think Cloudflare, GitHub, the language models) is free. That puts current costs at around $91 per month, which at the current pricing would need five solo customers or two premium customers to make this business profitable.
Which is a manageable challenge. And one I am looking forward to.
So, here we are. The beginnings of a new software product, out in the open from week one.
I’ll be sharing my journey as I build Podline into a business that can coexist with other players in the field. I will focus on serving serious podcasters and audio-centric creators who want to communicate with their listeners and manage the resulting data efficiently. Over the next days, weeks, months, and years, I’ll share updates, progress, experiments, screenshots, videos, and customer outreach strategies.
While working on this project, I’ll still be active in the community and continue writing my newsletter and podcast. I’ll also keep conducting interviews. Podline will remain a side project or, rather, one of the many small bets I am making. But it is an exciting new venture for me, and I can’t wait to see where it goes. Let’s see what we can create together — because that’s what building in public is about!
Now, I need a few deadlines. I want to make sure I don’t waste time fidgeting with features and bug-hunting for too long. I know that as an engineer, I can easily get sucked into these things and forget to actually do my marketing. This is why I want to “officially” launch latest January 6th, 2024. And by launch, I mean start actively marketing the product to the people it’s for.
This 4-week timeframe will give me enough time to dive into functionality, UI, and UX to build a tool that can “cross the chasm” to the not-so-technical prospects who are in my target audience. It’ll also give me time to kickstart partnerships and integrations to help Podline fit into existing workflows.
And, most importantly, I want to start gathering feedback both from my future customers and their listeners right now. This is why I would love to ask you to go to podline.fm, or, even better, podline.fm/arvid, and send me a voice message with your questions about the project, ideas, thoughts, recommendations, and all kinds of feedback. So please head over to podline.fm/arvid and check it out. I’d love to hear from you.
