406: Making Your Business Sellable (Even If You Never Plan to Sell)
Download MP3Hey. It's Arvid, and this is the Bootstrap founder. Today, I'll share how I've been preparing Podscan, and long before that, another SaaS business, to be ready to be acquired at a moment's notice. This episode is sponsored by paddle.com, my merchant of record payment provider of choice, and they've been helping me focus on Podscan from day one. It's been really helpful.
Arvid:They've been taking care of all things related to money so that founders like you and me can focus on the things that only we can build. And Paddle handles all the rest, sales tax, credit cards failing, all of that. Highly recommended. It keeps your books clean. It makes it very easy to communicate these internal financial things as well.
Arvid:So please check out paddle.com. Here's something that I've learned building and selling software as a service businesses in the past. A well run business is a sellable business. And, usually, a sellable business is also a well run business. There's kind of an equivalence here.
Arvid:And while a lot of founders have these grand expectations of gigantic exits, right, we all hope to sell for millions and millions, the real value of a business lies in something much simpler, a business that is well structured and operates following procedures and structured plans. And that structure alone is what makes a business valuable. Of course, there's more to this, right, as marketers, customers, but the structure is a signal. And why? Well, because a business that runs well is sellable because it's easily transferred.
Arvid:An acquirer looks at your business and they think, can I take it over easily? Can I put my own people in? And if they can, then it is a business that they're looking into maybe acquiring. So today, I want to share what I have done with Podscan to make this business as efficient as possible so that whatever might come, whether it's an extensive partnership or an acquisition or some deeper integration with another project, I am prepared. More importantly, the value capturing of the business can continue regardless of who's at the helm.
Arvid:That's also very important to me. There is this book by Michael E. Gerber, The E Myth, The Entrepreneurial Myth. And in this book, he describes on how to structure a business. And one of the ideas of a well run business, a well run system of entrepreneurship is to make yourself replaceable.
Arvid:So I don't necessarily want to replace myself at this point, but I want to be able to make that choice easily if I ever have to or want to in the future. So I can already start preparing the business to do this. So over the last couple months, I think I've talked quite a bit about the technical optimizations in the business, all the tech stuff, all the transcription stuff. And for a software business, the true value lies in learning about all kinds of challenges and baking solutions to those particular challenges into our products, about the infrastructure that runs it, that's for sure, and perpetuates it and maintains it. So when it comes to getting my transcription system down from costing potentially tens of thousands of dollars a day to just a couple of thousands bucks a month, that's the kind of thing that plays directly into the internal value of this business.
Arvid:Right? The less money I spend on expenses, the more margin I have, and the more value is actually captured by the business. And these kind of learnings, they're quite expensive to acquire. They take a long while. It took me over a year and a half to build this business to the point where it could run on those levels of expenses, let alone create enough value for customers to justify paying the subscription fees that I set.
Arvid:So the product and infrastructure optimizations clearly make the business sellable because those learnings themselves are also valuable. Running into things like database pressure from having gigantic text blobs of transcripts and then making them searchable. That is a problem that most SaaS businesses don't usually have. They don't have to ingest 50 to 70,000 individual conversations every single day, then make their full text version searchable almost immediately and scan them for keywords and have AI systems check them for contextual things. All of these learnings are pretty rare and focused on one particular kind of business, and they took a long while to get to.
Arvid:And they're priced into the effectiveness of the process of running this business. But when I talk about process here, I get to probably one of the biggest things that I've done to prepare the business to be sold or handed over eventually. I have documented every single thing. Obviously, documentation is true for most SaaS businesses. There's customer service docs, the help center articles about how to solve the biggest problems.
Arvid:Maybe there are API docs and something that your customer can use to integrate with your business, but that's not what I mean. On the infrastructure and development side, I've done several things that actually might be surprising if you at least come from a software as a service background or you're just building software for a living. First off, one of the things that indie hackers don't usually do, I bit the bullet and started writing tests for the software. This might be surprising to some who come from test driven development for whom this is perfectly natural, but I personally have never been writing tests for my software over the last couple decades. It just wasn't part of the kind of engineering culture I was in.
Arvid:I always thought we'll figure this out in production. If we get errors, we'll fix them as they come. We'll do this eighty twenty approach, get to somewhere quickly, and deal with the fallout later. What is it? Build fast and break things kind of approach.
Arvid:That has been true for most of the companies I worked for and most of the projects that I started. But it's really not like that. Certain things need to be tested. I figured this out. And 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 code base in their mind, and they have to rely on something else.
Arvid:Making a business scalable and making it possible for the business to grow without people having to expend a lot of energy trying to figure out how every single line of code interacts with the other. That's also part of making it more sellable. And testing has been important to me. And in doing so, I also commented the code base extensively. And this is something you can use AI agents for quite effectively.
Arvid:Just make sure you actually go through all the stuff that they create. If an AI agent writes tests, you have to go through the tests and make sure they actually test what you think they should test. If an AI agent comments on your code, ensure that you actually review the things as a code reviewer, as a test reviewer, and as a documentation reviewer maybe to actually check that it's truthful. Like, you have to make sure that if you build tests with AI, that the correct tests are built correctly. Like, you need to know what to test for and that the test is actually true.
Arvid:Now you might say, well, then I might just as well write them myself. Probably. Like, if you like that kind of stuff, I certainly don't enjoy it. But I have a much easier time going through a couple lines of code that somebody wrote for me and say, sure. Looks good than having to come up with every single thing myself, which I guess is just a normal reaction to AI generating code.
Arvid:Right? Some people wanna write it themselves. They really enjoy the act of writing code. I'm not one of these people. I enjoy the act of having code do the thing that I want.
Arvid:So I have a less hard time being a reviewer or a manager of an AI agent than a developer myself. Not that hardcore into development. It's a means to an end. Right? And so are these agentic systems.
Arvid:This means that you have to spend time in your code base. You can't just, like, click yes, sure, and deploy. It's not all just agents doing the work. You have to actively look into it and ensure that it's right before you commit it and before you deploy it. But this can help a lot in having a much better documented and more tested code base.
Arvid:And it actually makes the code base itself more compliant with agentic systems in the future 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 documented and tested code base are going to be much more reliable than once going over a raw undocumented untested code base. I figured this out. My steps were write documentation for every single major model controller and view and any kind of pattern and services and whatever in the code base. That was a prompt.
Arvid:And then I had Cloud Code go through these and just look at all of those files and write almost module level documentation where it was just like a little it's PHP for me. Right? I I work in Laravel. So it put twenty, thirty lines of comments on the top of the file saying what this file is for, what it's doing, what it's interacting with, what are the external components, all of that. I just had a prompt that made a document, these kind of things, like just first and foremost on top of the file.
Arvid:And then I had a sub prompt there that said, we'll now find the most important functions in this file that are used through most of the application. Right? The kind of hot code path kind of stuff and write explicit function level documentation for those functions as well. So now when I scroll through my code base, I have some functions that are just helper functions, don't necessarily have to be commented. But then there are some that have side effects that have some kind of massive impact on the flow of the application.
Arvid:They have good documentation on the function level too. And now whenever these get touched by an AI system, the AI will read this documentation and understand, oh, there are side effects here that I can be sure of without having to go through the whole code base. Oh, this is what it's meant to do. Right? Like all of this really helps create a better chance at a one shot solution to an agentic AI coding prompt.
Arvid:It's really helpful. And this will also make it much easier for people who then take over your software in the future to work with this. It's very, very useful. And it's not just codebase. Right?
Arvid:Codebase is where we encode the machine communication, like what machines have to do. But outside of the codebase, I document every single thing that has to do with development and deployment that people have to touch. I have an ocean database that contains all kinds of information on PodScan. How do you set up a local development environment? What versions of the software do we use for this?
Arvid:What are the steps? What tools should we install on a Mac? What on a Windows computer? What do I need to install? Where does it go?
Arvid:Screenshots, videos, all of that. Then maybe one of the most important things, how do we deploy to production? What are the services we use for that? Where are the servers that we're currently running? Is there a list of them?
Arvid:Where's the IP? Right? What credentials do we use? We have a fleet of API servers that do the transcription and analysis. Where are they?
Arvid:Where are they hosted? How do we deploy a new one? What's the command list that needs to be run if a new server has to be set up? How are these servers provisioned? Are they deprovisioned?
Arvid:Like, how do they connect to our main database and that kind of stuff? And then ultimately, how do we troubleshoot? What are common issues that we have to deal with? And here are a couple commands and how to search for certain problems. Right?
Arvid:Is there a RAM issue? Well, how do you find out the thing that hogs the memory currently? Is our Redis database ballooning? How do we find the biggest keys? All of these things are not novel.
Arvid:I think most projects have these kind of troubles and they have the solution for that. But I have it all in one document so that anybody, me and anybody else, who runs into an issue can very quickly pick it up and figure it out. 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, or a little postmodem after the thing had been resolved. The moment I solved a problem like disk was full or 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.
Arvid:Or ran into the 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?
Arvid:If not, what's the next step? What's the next thing? All of these things are encoded in postmortem articles that I wrote whenever something happened, either during or after. And now I can search for terms similar to what happened in the past and find a solution for the thing that is happening now. Anything that has to do with customer data and things that customers want to do with their data has its own page in the most common operations.
Arvid:That's important too, because when a customer reaches out, you really wanna be able to respond quickly. Say, customer wants a certain podcast to be deleted. Like, they deleted it on all these different platforms and it's still in PodScan. How do we do this? Where in the database can I find it?
Arvid:Can we do this in the interface? Can the customer do it in the interface? All that stuff needs to be encoded for a person that is not me. Of course, I know it, but if I have to hand this over to somebody else, I want it to be a place for them to go to check and see exactly what to do. Or customer needs their subscription canceled and wants to extend to another plan or can't do it from the front end, has issues with that, how do we handle that?
Arvid:That's critical. Right? If we respond well, there's money in there. And if we don't respond, they just cancel. So this needs to be figured out.
Arvid:Documentation that I have also contains fragments on how to respond to certain things. Right? Just text to the premade text. What's the text we use if somebody's frustrated because they can't log in? Do we tell them, well, have you checked your spam folder?
Arvid:Or are you trying to log in with Google? We don't even have this feature. Right? This kind of stuff. We don't wanna type manual responses every time because sometimes people just have similar problems.
Arvid:We've preformulated responses for situations that happen often when people have issues due to their own personal limited technical capacities. It's really if somebody isn't really capable with tech, a media person, they run a podcast, they are good at talking, but they don't really know how the web works. That's fine. Right? We need to be able to help them.
Arvid:And for that, we have a pre formulated response that worked for other people like them. That's just an optimization here. And then there's also strategic docs, documentation for the business strategy itself. So I have a list of all my dream customers in my database, all the customers I really want to use the product because I think it would be perfect for them. 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.
Arvid:And I have so many docs. Just gonna list what I see here. I have a knowledge base of emergency procedures. I have documentation around features and how to communicate them to customers because I also send out emails to customers on new features, kind of telling them, oh, here's more value in the product, value nurturing emails. So that stuff makes it into the docs.
Arvid:I have a running list of new features. And when it's big enough, then I condense it into a newsletter, delete it from the list. I have architecture documents describing what the database looks like, a schema, but also, like, how relationships are meant to work, what each table looks like, how these things interact. I have documentation of our data export architecture on s three for enterprise customers, which is really important to have so that people don't have to use the API to download, like, millions of things. They can just download and export.
Arvid:Right? That's a big feature for our largest customers. I have the rolling list of IP addresses and usernames for logging into all servers. That's roughly 20 to 30 individual servers right now. Obviously, credentials are not in my Notion database.
Arvid:There is a password vault somewhere that has all these credentials that I have to go into to connect eventually. But just to know where to go, that's all in Notion. I have a setup and maintenance document system for each server type, bug hunting documents also, like they show the most likely problems, how to deal with them, and then update procedures for how to update PHP, how to update the search systems that I have and other components. That's my docs. They are very extensive even for a business that is just run for one person, but I would like to have everything figured out and would like to be able to pass this on to somebody who has no idea how the system works and for them to find a way through the system in a couple hours.
Arvid:Hence, these docs. Another thing that's really needed to make a business sellable is keeping all those passwords and accounts separate from my personal stuff and in a vault, in a password vault that's quickly and easily shareable with a potential acquirer or even your team. Right? It's just have all of this stuff in a central location that's not personal. That's something that I've learned last time we sold a business.
Arvid:Sometimes handing over your business can be as easy as giving somebody a login and a password and some kind of code to a password vault that contains all the secrets, all the docs, all the logins, all the passwords for your whole business. That can be it. Like, Potscan is prepared for this in two particular ways. First one, I keep all password secret documents in the vault that's shareable with somebody separate from my personal passwords, my Google, my email, all of that stuff. The services that have personal logins, they stay outside of that vault.
Arvid:They're in a different one. And each account that 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, hosting services, deployment, marketing services, payroll is logged in with Podscan credentials. So there's nothing personal in there. If Podscan ownership changes, I hand over that Google account and other people can log in as that account.
Arvid:I don't have to share my personal email account or passwords with anybody so they can kind of try and log in somewhere. No service is running on any personal account of mine. If they were initially, because I didn't have a Podscan domain yet when I started hosting or my domain provider, I changed the login and connection to the podscan.fm email accounts at that point. At some point when I could, I did change it. And that's a very important thing to have this distinction.
Arvid:Obviously, you want your business money in its own account too, like, in a business bank account, but it starts with the credentials. And they need to be completely separate from your personal accounts. I'm hammering on this point because so many people forget. And then they try to sell their business and then they have their personal Google account involved in something that is very business centric. And now somebody wants to buy your business, but you don't want to give them access to your personal account and that becomes a point of contention.
Arvid:You don't need that. So don't have it. Beyond all these systems and product optimization documentation in separate accounts, I recommend keeping your books in order at all times. Like, I don't mean, like, have all your invoices figured out. I mean, actually have profit and loss statements for the current year at all times, accurate ones, and update them every month or so.
Arvid:I always have this ready to share with a potentially interested party because you don't want to sit there for like three days trying to figure it all out when somebody's asking you, hey, can you send me this thing? And I maintain a statistics page too, like an internal one that shows how many customers we have, how much data we have, how many insights we have, like, just a lot of stuff to show a potentially interested party. I have cohort analysis data. I use ProfitWell by Paddle because Paddle is my payment provider for the product. So they have ProfitWell, which is effectively analytics data inside tool, and I can very easily show cohort information to anybody who's interested, either via screenshot or I can share a page there so they can see what the customer situation is looking like.
Arvid:I always have that up to date. It is automatically updated, which is great. And I always have immediate visibility into my retention rates, my churn rates, and my cohort demographics all through ProfitWell as well, because I need to know these numbers to just figure out where we're heading, right, what the projection is. All of this data is available if somebody is truly interested in the business and it's collected at all times. So keep your financials up to date and make them shareable so that people can look into it with you during due diligence or before when there's interest.
Arvid:My dear friend Kevin McCurdle was on this podcast before, and we talked there about having a yearly acquisition retreat kind of a sellability retreat where you think about, do I wanna sell? And if so, what do I need to do? And if not, what can I do so that if I would wanna sell, I'm ready to do it? It's fine if you say, no, I don't wanna sell. That's wonderful.
Arvid:Right? 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. It's always good to think about this, but it's perfectly fine to say, nope, not selling. I'm gonna keep this for a while. It's just that life throws you curveballs from time to time and having things in place so you're capable of doing this without too much additional work.
Arvid:I think that's just beneficial. So once every now and then it is good to sit down and consider what would need to be done if you were in a position that you wanted to sell this business. And as I'm in this phase where there's acquisition interest for Podscan right now these are the things that I recommend thinking about because I think about them myself. And it doesn't really matter if you're starting a business or already a couple months or years into it. It's always good to just keep this in mind.
Arvid:The beauty of all this prep is it's not just about the potential exit. Every single thing that I've described, documentation, like keeping accounts well separated so you can share them more easily, it just makes the business better to run day to day. Documentation means I can onboard people faster, onboard people that help me faster. Testing means that fewer bugs reach customers. Financial clarity means better decision making too.
Arvid:Separation means cleaner operations. A sellable business is simply a well run business and the other way around. And a well run business creates more value for everybody, not just you, but also your customers, your team, and yes, your potential future owner, the acquirer of your business. So even if you never plan to sell, just build like you might. Your future self will really thank you.
Arvid:And that's why I have all of this in place at all times, not because I'm always looking to sell, but because it makes Podscan a better business. And that's it for today. Thank you so much for listening to The Bootstr Founder. You can find me on Twitter at avid kahl, a r v I d k a h l. If you wanna support me in this show, please share podscan.fm with your professional peers and those who you think will benefit from tracking mentions, the brands, businesses, names of podcasts out there.
Arvid:Podscan is a near real time podcast database with a really solid API. You can build whole businesses on top of this, and people do. So please share the word with those who need to stay on top of the podcast ecosystem. Thanks so much for listening. Have a wonderful day, and bye bye.
Creators and Guests
