Dear founder,
As I'm building yet another software service business after having built and sold one back in 2019, I keep wrestling with a fundamental question that might sound simple but has profound implications: What do I actually own in this business?
And before we get to that, a word from our Sponsor, Paddle.com. They're a great example for things that I consciously delegate to someone else, and I'll get to that later when I talk about owning customer relationships. I use Paddle as my Merchant of Record. They take care of all the taxes, the currencies, tracking declined transactions and updated credit cards so that I can focus on dealing with my competitors (and not banks and financial regulators). If you think you'd rather just build your product, check out Paddle.com as your payment provider.
"What do I actually own" is a question that becomes particularly urgent when you realize that modern software businesses exist in this fascinating paradox. We're building increasingly valuable assets—businesses that generate revenue, grow in value, and can potentially be sold for significant sums—yet we have less direct control over the infrastructure than ever before. We're essentially building castles on rented land, and the implications of this go far deeper than most founders realize.
The Dual Nature of Business Value
Let me start with why this matters so much. A business is not just a place where you work. It's both something that generates this constant stream—maybe a salary or dividends, or you reinvest the money that the business makes into itself. But in the end, the business itself grows in value. And if you own that value, and if that value is capturable by you, then you effectively get value twice. You get value along the way through operational income, and then you get the expected value over the course of the business running—that's something that people could buy from you.
I'm always thinking: How can I balance how much value the business creates for me today and how much will it potentially create for me or somebody else in the future? And here's the thing that's funny enough to be able to sell something—you have to actually own the asset.
This becomes a particular problem for building software businesses in this world of vibe coding and hosted everything. If you manage to build a profitable business on Lovable or on v0, or on any of these other easy-to-deploy, easy-to-prompt vibe coding platforms, then one of the interesting questions becomes: How much control, how much ownership do you actually have? Not just over the business as an entity—that's a legal question—but how much control do you have over the operational durability of your business?
The Infrastructure Dependency Chain
We live in a world where almost everything you could potentially run as software, or as an underlying foundation for a software business, also exists as a rentable version—a much more affordable, rentable version that somebody else is running for you. I'm thinking about Platform as a Service stuff like Heroku, or even Infrastructure as a Service like AWS or Google Cloud. Or platforms like Vercel, where you just ship some code and then everything magically runs for you.
Even for my more recent side projects for Podscan, I've started to run things on Laravel Cloud, which is effectively a Platform as a Service provider for Laravel. I just deploy my code there, and they automatically spin up the services that are needed. They spin up the database, they spin up the Redis caching layer, they spin up file systems—and none of this I need to manage anymore.
With Podscan, I still have some control over the infrastructure, but that infrastructure is also, at least in parts, hosted with Infrastructure as a Service providers. I have a couple of bare metal machines that are mostly running my transcription and my search engine, but the main application is, for reliability and scalability reasons, hosted not on a VPS, but with an Infrastructure as a Service provider.
We are becoming more and more dependent on externalized services that are deep at the core of our businesses. And this dependency creates both opportunities and vulnerabilities that we need to carefully consider.
The Technology Choice That Haunted My Exit
Let me tell you a story that really drove this home for me. I had this technology choice problem with my previous business that I sold, Feedback Panda, which was built on top of a rather rarely seen web server called Phoenix in the Elixir programming language. And that, in many ways, quite limited who would be able to buy our company or buy our product, because they would have to have an Elixir engineer.
Whereas everybody has access to many, many PHP and Ruby and JavaScript engineers, Elixir engineers are still in high demand, and the engineers that can work with this technology have spent many years figuring it out—they are more expensive than others. So in a way, that choice probably precluded us from several buyers, potential buyers, just by the mere tech choice that we made.
Even though we had this wonderful application that we thought we owned, when somebody asked, "Well, can I buy it from you? What tech do you use?"—your ownership, not just in terms of the software, the code itself, but also the decision of which code to write, matters tremendously.
For me, scalability and sellability are essentially the same thing. Either I scale the business or somebody else scales it. The question becomes: Do my technology and ownership choices work for that? Did I make the right choice at the right time, and do I control enough of it for somebody to either build more out of it or take it and build something bigger from it?
The GitHub Dependency We All Pretend Doesn't Exist
This affects not just what code I write and where it's running, but also where my code is stored and how I deploy it—from where I control it in version control to the actual servers that need a new version or need a fix or need a rollback.
Many a day on Twitter, I see people saying, "Well, GitHub is down. Can't work today." As funny as it is to see people posting memes about that old XKCD comic about code compiling and people fencing on their office chairs because they have nothing else to do, an outage of one of these infrastructure systems—not of the running code, but of the deployment and development of code—that's pretty critical to a business that has to deal with bugs and new developments every single day.
Being able to deploy code, not just through a pipeline that involves a third-party service, but from your local development system in a pinch—particularly for bootstrapped founders, for people with small software as a service businesses that do not have massive checking and balance of power requirements—that's something you need to still own. You need to still own a way to deploy in a pinch to a server, even if part of your code deployment infrastructure is not working.
Building Resilience Through Strategic Redundancy
I've figured out how to turn off and on particular parts of my deployment procedure that may or may not require external servers. I lean heavily into caching of these things so once I have them, I can always reinstall the exact same thing on the exact same server, and I lean into just being able to skip the installation process and copy over old data when I need to.
Fortunately—and you may have opinions about this—I'm working with PHP as my programming language. So I have, ultimately, the capacity to just SSH into my production server, go to the folder where the PHP file that has a bug is located, and manually adjust that file if needed. If everything broke down, if GitHub didn't work anymore, if my installation system would fail every single time, I could still manually correct code like it's the 90s. And that, to me, is also ownership.
Let me give you a concrete example of how I think about this layered approach. For authentication, I use an authentication library that allows me to connect to an external service. I have an authentication system that works locally in my PHP Laravel application, but I could also allow people to click a button and log in through Auth0. This is a layered, abstracted approach where there's always a local fallback.
I have the same thing with my AI usage in the backend. Whenever I do an AI analysis of a transcribed podcast episode that came into my system, I run the best available local language model that I have. If that is busy, I try to go to OpenAI. And if OpenAI is throwing errors because somebody plugged in the coffee machine next to the server at OpenAI again, then it falls back into a queue so a local system can take care of it.
You have to think about what could break and what are your alternatives. What can you fall back on? Fallback systems for every single thing you have might be very interesting, and they need to be tested.
The Customer Relationship Paradox
Here's where it gets really interesting. I use Paddle as my payment provider, and they are merchant of record, so they kind of own the customer relationship. But because of this—because it makes so many things easier—I'm fine with that. I'm actually quite happy about this, because they take care of so many things that would add extra complexity to my business. That is their business to solve.
But being aware of them owning the customer relationship, or at least the payment relationship with the customer, I regularly export every single thing from the Paddle platform through API calls and through reporting exports. I have a list of all my customers and all their subscriptions on my Dropbox somewhere, and on my local computer, so that even though that service may own the relationship or might experience problems on occasion, I always still have control of the data, and I can connect with the people that are my customers.
Think about it: You're renting on rented land. You're renting out something to your software as a service customers, and you yourself are a software as a service customer to somebody else. In this relationship, you need to make sure you try to own as much of the relationship with your customer in terms of actual business interaction, and to own, as much as possible, the circumstances and the data of your software product on the other side of things.
The Ownership Framework for Modern Founders
So here's what I've learned about navigating this ownership paradox:
First, always ask yourself: Who would not want to buy your business because of the choices that you made? Because of the technological choices, the infrastructure choices you're constantly making, and because of the presence or lack of documentation of these processes?
Second, think about ownership almost as decentralization of data. Do I have a full copy of all my customers with their emails and their payment information, if needed, or at least a way to reach them to set up an alternative should my payment provider fail?
Third, for every external dependency, build a fallback. This doesn't mean you need to rebuild everything from scratch. It means having a plan B that you've tested and know works. Whether it's being able to deploy code manually when your CI/CD pipeline fails, or having local authentication when your auth provider is down, or maintaining regular exports of critical data.
Fourth, consider the transferability of your choices. When you make these initial decisions—do I build my own authentication system? Do I use a library that everybody uses? Do I use a service like Auth0?—think about how easy it would be to hand over these components to a potential buyer or even to a team member taking over your work as the business grows.
The Path Forward
The option to sell always exists with a successful business, but the option to grow and to invest in new team members taking on work—delegating—that means somebody else will have to take care of it as well. Even though my ownership is retained, access needs to be shared. And access needs to be shared to the point where I don't have to touch anything at all anymore.
This is the reality of building software businesses in 2025. We're more dependent on external services than ever before, but that doesn't mean we have to sacrifice ownership entirely. It means we need to be more intentional about what we choose to own, what we choose to rent, and how we maintain optionality in between.
The businesses we're building today are incredible feats of leverage—we can create million-dollar companies with tiny teams precisely because we don't have to own and operate every piece of infrastructure. But with that leverage comes responsibility: the responsibility to understand our dependencies, to build resilience into our systems, and to maintain enough ownership that we can still capture the value we're creating.
As bootstrapped founders, we're not just building products. We're building assets. And an asset you don't truly own is just a job with extra steps. The key is finding that balance—leveraging the incredible tools and services available to us while maintaining enough control that when opportunity knocks—whether that's scaling or selling—we're actually in a position to answer the door.
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