Dear founder,
Here's something I've learned building and selling a software as a service business: A well-run business is a sellable business. And while a lot of founders have grand expectations of gigantic exits, the real value lies in something much simpler—a business that's well-structured and operates following procedures and structured plans. That structure alone is valuable.
Why? Because a business that runs well is sellable because it's easily transferred. It has inherent value that it's capable of expressing and capturing because of its internal structure.
Today, I want to share what I've done with Podscan to make this business as efficient as possible, so that whatever might come—whether it's an extensive partnership, an acquisition, or a deeper integration into another project—I'm prepared. And more importantly, the value capturing of the business can continue regardless of who's at the helm.
This issue is sponsored by Paddle.com, my payment provider of choice for Podscan.
The Technical Foundation: Where Real Value Lives
Over the last couple of months, I've talked quite a bit about the technical optimizations in the business. For a software business, true value lies in learning about all kinds of challenges and baking solutions to those challenges into your product—into the infrastructure that runs it, perpetuates it, and maintains it.
When it comes to getting my transcription system down from costing potentially tens of thousands of dollars a day to just a couple thousand dollars a month—that's the kind of thing that plays directly into the internal value of the business. The less money you spend on expenses, the more margin you have, and the more value is captured by the business.
These learnings are expensive to acquire. It took me over a year and a half to build a business to the point where it could run on those levels of expenses, let alone create enough value for customers to justify paying subscription fees.
The product and infrastructure optimizations clearly make the business sellable because those learnings themselves are valuable. Running into things like database pressure from having gigantic text blobs of transcripts and making them searchable—this is a problem most SaaS businesses don't have. They don't have to ingest 50 to 70,000 individual conversations every single day, make their full text versions searchable almost immediately, scan them for phrases, and have AI systems check them for contextual things.
All of these learnings took a long while to get to, and they're priced into the effectiveness of the processes.
The Documentation Imperative
But when I talk about process, I get to probably one of the biggest things I've done to prepare the business to be sold: I have documented every single thing.
Obviously, there's customer service documentation—a help center with articles about how to solve the biggest problems. But on the infrastructure and development side, I've done several things that might surprise you.
Biting the Testing Bullet
First off, I bit the bullet and started writing tests for the software. This might be surprising to some who come from test-driven development, but I personally have never been writing tests for my software. I always thought, "We'll figure this out in production. We'll do an 80/20 approach."
But it's really not like that. Certain things need to be tested. Certain things need to be made sure that they function, particularly if you plan to have a team where not everybody can have a full mental model of the codebase and has to rely on something else. Making a business scalable—making it possible for the business to grow without people having to expend a lot of energy—is also part of making it more sellable.
Testing has been important, and in doing so, I also commented extensively. This is something you can use AI agents for quite effectively—just make sure you actually go through all the stuff they create. If AI agents write tests, go through the tests and make sure they actually test what you think they do. If AI agents comment on your code, ensure you review these things as a code reviewer, test reviewer, and documentation reviewer to actually check that it's truthful.
This means you have to spend time in your codebase. It's not all just agents doing the work. You have to actively look into it and ensure it's right before you commit it. But this can help a lot in having a better documented, more tested codebase.
It actually makes the codebase itself more compliant with agentic AI systems that now have more resources to pull from, that now understand better what certain things are for. So the results you get from having an AI agent go over a well-commented and tested codebase are going to be more reliable than ones going over a raw, undocumented, untested codebase.
The Notion Database of Everything
Outside of the codebase, I documented every single thing that has to do with development and deployment. I have, effectively, a Notion database that contains all kinds of information on Podscan:
- How do I set up a local development environment? What are the steps? What do I need to install, and where does it go? Screenshots, videos, all of it.
- How do we deploy to production? What are the tools? What are the servers we're currently running?
- We have a fleet of API servers that do the transcription and analysis. Where are they? What's the command list that needs to be run if a new server has to be set up? How are these servers provisioned? How do they connect to our main database? What's the IP of the server?
- How do we do troubleshooting? What are common issues we have to deal with?
All of this happened organically over time. Whenever something happened, I would just write an article on how to fix it as I was fixing it. The moment I solved a problem—like a disk was full and I needed to figure out where the files were that could be deleted—I wrote an SOP, a standard operating procedure on how to deal with a full disk. Or when I ran into a RAM issue: What happens when RAM is at 80%? What do I do? Where do I check? Is there something I can restart to see if that helps? If not, what's the next thing?
All of these things are encoded in post-mortem articles that I wrote whenever something happened. Now I can search for terms similar to what happened in the past and find a solution.
Customer Operations Documentation
Anything that has to do with customer data and things customers want to do with their data has its own page with the most common operations:
- Customer wants a certain podcast deleted. How do we do this? Where in the database? Can we do it in the interface?
- Customer needs their subscription plan canceled or wants to extend to another plan but can't do it from the front end. How do we handle this?
The documentation also contains fragments of how we respond to certain things. What's the text we use if somebody's frustrated because they can't log in? We don't want to type manual responses every time. We have pre-formulated responses for situations that often happen when people have issues due to their limited technical capabilities.
Strategic Documentation
I keep a list of all my dream customers in my database. So if I'm trying to reach out to a new kind of customer, I have a list of 20, and I can use AI systems to find similar lookalike customers to reach out to.
I have:
- A knowledge base of emergency procedures
- Documentation around features
- A running list of new features (when it's big enough, I condense it into a newsletter and delete it from the list)
- Architecture documents describing what the database looks like, what each table looks like, how these things interact
- Documentation of our data export architecture on S3 for enterprise customers
- A rolling list of IP addresses and usernames for logging into all servers (roughly 20 individual servers)
- Setup and maintenance documents for each server type
- Bug hunting documents showing the most likely problems and how to deal with them
- Update procedures for PHP, search engines, and other components
The Separation Principle
One other thing that's really needed to make a business sellable is keeping all the passwords and accounts both separate from my personal stuff and in a vault that's quickly and easily shareable with a potential acquirer.
That's something I learned last time we sold a business. Sometimes handing over your business can be as easy as giving somebody a login and password and a code to a 1Password vault that contains all the secrets, documentation, logins, and passwords for your whole business. That can be it.
Podscan is prepared for this in two ways:
First, I keep all passwords and secret documents in a vault that's shareable with somebody, separate from my personal passwords—my Google, email passwords, or all the services I have personal logins for stay outside.
Each account I use for Podscan is bound to either a Google login or a regular username/password login using Podscan credentials. Everything Podscan uses—from logging into hosting services, deployment services, marketing services, to payroll services—is locked in with Podscan credentials.
If Podscan changes ownership, I can hand over that Google account and other people can log in. I don't have to share my personal email account and password with anybody. No service is running on any personal account of mine. If they were initially (because I didn't have a Podscan domain yet), I changed the login and connection to the podscan.com or podscan.fm email accounts.
This is very important—to have that distinction. Obviously, you also want your business money in its own account, but it starts with the credentials. They need to be completely separate from your personal accounts.
Financial Preparedness
Beyond system optimization, product optimization, strong documentation, and separate accounts, I recommend keeping your books in order at all times. Generate a P&L for the current year—a profit and loss statement—every single month or so. I always have this ready to share with potential interested parties.
I maintain:
- A statistics page showing how many customers we have
- Cohort analysis (I use ProfitWell by Paddle since I use Paddle.com as my payment provider)
- Immediate visibility into retention rates, churn rates, and cohort demographics
All of this data is available if somebody is truly interested in the business, and it's collected at all times. Keep your financials up to date and shareable so that people can look into it with you during due diligence.
The Sellability Retreat
My dear friend Kevin McArdle talks about having a yearly "acquisition retreat"—a sellability retreat where you think about: Do I want to sell? If so, what do I need to do?
It's fine if you say, "No, I don't want to sell." It's always a good idea to be sellable because you never know if in a month or two, certain things change in your life and an acquisition opportunity opens up, or you need to get rid of the business, or you need to find a way forward for the business without you.
Life throws you curveballs from time to time. Having things in place so you're capable of doing this without too much additional work is highly beneficial.
Why This Matters (Even If You Never Sell)
As I'm in this phase where there's acquisition interest in Podscan, these are the things I recommend thinking about whether you're starting a business or already a couple months or years into it.
The beauty of all this preparation isn't just about the potential exit. Every single thing I've described makes the business better to run day-to-day. The documentation means I can onboard help faster. The testing means fewer bugs reach customers. The financial clarity means better decision-making. The separation means cleaner operations.
A sellable business is simply a well-run business. And a well-run business creates more value for everyone—you, your customers, your team, and yes, any potential future owner.
So even if you never plan to sell, build like you might. Your future self will thank you.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment