Dear founder,
Here's the thing: I'm about to share all the reasons why you should never, ever start a software business.
And yes, I'm fully aware that I'm talking to an audience of software founders. This is somewhat sarcastic, somewhat ironic twist on the great things about entrepreneurship.
But here's what I've realized - talking about the problematic sides of entrepreneurship might actually help somebody who already has this mindset to say, "Yep, I'm going to do it anyway," or somebody who is on the fence to reconsider - maybe taking it slow and starting it as a side project instead of jumping into it full time.
And for founders who are already on that journey? I'm just going to share the little things I've realized along the way, so that maybe you can recognize them at an earlier stage.
A quick word from our Sponsor, Paddle.com. If you, for some reason, DO choose to start a software business, look into Paddle. I use Paddle as my Merchant of Record for all my software projects. 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.
So let me get into the mindset here. Why should you never start a software business as a solopreneur, as a bootstrap founder?
The Loneliness Nobody Warns You About
First off, it can get incredibly lonely. Software entrepreneurship means that you're going to spend more time with your code, with your product, with making sure it runs, making sure it provides the value that people may or may not pay money for. You're constantly going to be interfacing with computer systems, and when you rarely interface with your customers, it tends to be in a negative context.
Sure, you can have a nice conversation. You can turn a bug report into a very friendly interaction with a prospect or with a customer. A complaint or a help request - you can always turn that into something positive. But it starts out as a point of friction, as a point of challenge. So any human interaction that you're likely going to have with your customers is going to be one of being challenged, seeking help, or - and this might be even worse when you come from a technical perspective - somebody who is not interested in your product. You try sales outreach, you try marketing. People come in. They see it. They don't want it. They don't even come in. You send emails. People say, "Stop sending me emails."
That can make you feel fairly lonely, particularly if you're not doing this with a group of people.
The way out for me is just being very active in my founder online community - being on Twitter, being in Slack groups, reading people's blog posts, writing blog posts and interacting with my readers, having a podcast, having interviews on the podcast, talking to people. Just giving my brain the feeling that it's real, that I'm not alone.
But there are different kinds of lonely. There's the lonely that happens over time, where you just feel like another week went by and I only had like two real conversations with people during my work hours. This is a kind of sad, prolonged lonely.
But then there's also the lonely in the moment. It's two o'clock in the morning, for some reason your server has decided to run out of memory, and you are trying to restart it to make sure that the product comes back up, but then it fills up again within five minutes, and you need to restart it again. So you need to fix the problem while you're also triaging the problem, while customers start emailing you that the stuff doesn't work.
There's a loneliness in that moment where you are the sole defender of the castle and you have to keep the invading hordes at bay, but also tell your inhabitants that things are going to be okay - while sharpening your swords and patching up your armor at the same time. It's just a lot of pressure in moments where you don't have many people around you to help you.
Becoming a Lightning Rod for Problems
Here's another reason why you should never start a software as a service business: particularly in the early stages where you are the only person responsible for the business, you're responsible for everything. And things will pull at you with unknown, previously unknown priorities.
At some point you thought you had figured it out. You've developed an outreach campaign that brings in new leads, and they eventually convert. And all of a sudden, one of the service providers that you use for your emailing starts experiencing outages every other day. It gets worse and it gets worse, and you suddenly have to completely rebuild your email infrastructure because that service needs to be replaced.
So not only do you need to replace a running system and run an outreach process that is mapped onto your email automations, you also need to find a comparably capable provider somewhere else that you can then integrate into your system to rebuild the exact same system. And that came out of the blue, took three days out of your week, and all of a sudden, everything else you wanted to do - the feature you promised your customers - none of that got done.
Lightning is going to strike all the time, and in a way, avoiding it makes it worse. So you have to become a lightning rod for problems. You have to go towards the problems any time they might appear.
As somebody who previously was a salaried engineer, when I started software development, I was taught to avoid problems - to avoid bugs, avoid complications, avoid challenges, make sure that they can never appear. And then when I became an entrepreneur, it was like, no, no, I have to get to the challenge before the challenge gets to me. I have to make sure that I preempt the chaotic explosion and make it happen early, so that I can see what parts of it get burned, so I can build a stronger, fireproof system around those systems.
You know that meme with the airplane with the bullet holes? It's commonly used to say that people focus on the wrong things when they try to improve something. The US engineers thought that only the areas where planes that returned from fighting had a lot of bullet holes should be strengthened, forgetting that the areas that didn't receive many bullet holes were likely representative of the fact that if a plane was shot in those areas, it wouldn't even make it back home. Selection bias.
That's kind of what this is. You want the plane to explode quickly so you can see where you need to strengthen your system more. Because if things keep working and keep working, they will blow up in your face anyway. Any sufficiently complicated system will eventually have some kind of explosion - either through latency accumulating, or external connections dropping, or some kind of dependency not working. There will be something at some point, and you will need to be there.
The 24/7 Reality Check
Which brings me to the third point: you are effectively working 24/7. You're not putting all your efforts in 24/7 - you're still going to go to sleep, and most nights, it's going to be great. You wake up, you go to work, you keep working on it. You take care of all the customer service messages that came in overnight, and you send out emails the next morning. There will be some kind of structure to your day.
But then there will be days where this doesn't matter. Where at three in the morning, you get a notification - an SMS or a push notification to your phone, which you hopefully have configured to ignore most things but let these things through - and it tells you your website is not reachable. Your external monitoring, the Pingdoms and Uptime Robots, they have tried to ping your website and it's not responding. And you have customers that have an SLA - a service level agreement - with you that the maximum daily downtime is an hour or 30 minutes. You better get going.
This is the moment where you work 24/7, because you're always on call building a software service business. Even if you use the best hosted application services, if you use the best hosted databases, there is going to be something. Something will happen. And even if it's just the connective tissue between the services that sometimes breaks and you just need to restart your server, it's enough at three in the morning to pull you out of your routine.
And that's something that is unavoidable until you hire. And then you need to hire somebody who is going to be reliably there and knows exactly what to do, which is still a different challenge. Because likely what's going to happen when you hire somebody to fix this for you is that they're going to be woken by the alerts, they'll spend five minutes trying to figure out what's going on, they're going to try and implement a fix, it doesn't work, and they wake you up 10 minutes later. In the beginning, that is quite likely the kind of event chain that's going to happen.
Running a software business is not going to make this easy for people with children or with other dependents that they need to take care of, or who want to have a solid distance from the work that they do. Obviously, there are still many parents, many caretakers, people with professional distance who end up building successful software businesses. But it's certainly a higher investment of focus and attention.
The Inertia Mountain You Must Move
Here's why you really shouldn't build a software as a service business: it's incredibly hard to convince people to change what they currently have. Most software as a service solutions are new versions or better versions of things that already exist, and the inertia that people have that prevents them from changing from their existing solution to a new solution - it's incredibly hard to overcome.
People will go out of their way to not change anything about their work. And this might be different in certain audiences, but I can tell you, it takes a lot of effort to convince somebody not to just give you money - that is already hard - but to change their process in a non-trivial way.
This is particularly challenging because in the beginning, as you start your business, you have a lot of assumptions. Otherwise you would never get anything done. You have to assume a lot of things, and those assumptions - some of them are likely not correct. So you have to course-correct all the time. And a product that is in this path of the first couple years of course-correcting, of figuring out what exactly it needs to do, is even harder to sell, both as a solution and as an actual thing that costs something.
For you to learn how to talk to people in a way that you can actually assuage their fears, actually convince them that they're missing out on something if they don't use this - speaking the language, learning the language, learning how they prioritize, how they focus on their challenges - that takes a long, long time in any field. And it takes a lot of communication with customers, which, as I said earlier, sometimes is not happening that much because you're so bogged down with the actual product that you want to be able to sell to people.
The Shifting Sands of Constant Change
Don't build a software business if you want to feel secure in your choices and assumptions. Because not only does your product change to meet the job to be done of your customers, but the jobs that your customers have, the internal processes, the internal requirements - they change constantly as well. And this is true for smaller businesses just as much as it is for enterprise businesses.
Things are changing all the time. You will always have to keep up with things. You will always have to make sure that if somebody changes their process, you can still adequately map your process towards this. And then you have to think about the fact that the whole industry is changing - new people join the industry, some people drop off. New regulation hits the industry. New technologies get developed, new standards defined. New provisions are formulated. New laws are enacted for or against certain things. New perspectives are being integrated into people's processes. New taboos come up. Old taboos break off.
It is a constant struggle to figure out what is going on and how you have to respond to things. So if you would like to feel like you know what you're doing, choose an occupation that you can do for five years straight and not expect much change. I don't know, become an oil painter. Oil paints have been chemically similar for the last couple hundred years. Of course, there are new developments in that technology as well, but the act of painting, the act of making art, does not constantly shift as much as the requirements and minuscule details and processes of people who use software tools might.
The Deprecation Treadmill
And then there's the technology layer. Everything is getting deprecated and changed all of the time. If you choose the current version of Linux to install on a server, two and a half years from now, the long-term support for this is going to end. If you choose MySQL 8-point-something today, next year AWS will retire this version and charge you double if you want to keep it running. If you use an API, something is going to change, or you're going to be asked to migrate to a new version because only that supports whatever new regulation - SOC 2, or some banking regulation in India, or something like that.
It is bizarre how often you have to chase changes and implement them so you can still do the exact same thing as you've done before. Things get deprecated and things have to be maintained. Because it's turtles all the way down - you choose an infrastructure as a service provider that has to maintain a certain set of software, and then they have to upgrade it because of security concerns, and now you have to upgrade your integration, and the people using your product now have to upgrade because something works slightly different.
It's this infinite chain of tiny changes bubbling up and down and making people change the things that are already running for them. Ideally, you start containerizing and isolating things, and you make sure that they are compatible, and you have alternative ways of doing it. But in the end, you'll find that it's always going to stop you left, right and center, because somebody changed a dependency somewhere.
The Ownership Paradox
And you have to own it. You have to both deal with it in the moment, and if it makes your software more unstable, if it makes your business wobble, you have to tell your customers, "We're experiencing a problem." You're not supposed to say, "Hey, it's AWS's fault" or "Our email provider isn't working." You have to say, "We have a problem with our email. It'll be back in a minute." You have to own these things that are not your fault.
And that's one big thing about running a software as a service business. Ownership is limited in many ways. It's already hard to own a software business because you're just building rented infrastructure on rented land. But you have to think of the fact that there are so many variables and so many externalities to running a software as a service business that it will never be something that you could just freeze and say, "This is it forever." Things change all the time.
The Plot Twist: Why It's Actually Worth It
I think these are sufficient reasons to consider maybe becoming a farmer or an oil painter. But realistically, none of these are problematic enough to not be worth it.
Because one of the things that building a software business allows you to do is to build a super high-leveraged, high-revenue company that is very, very interesting for PE companies, for other companies to acquire, and that might net you a couple million at the very least, if you run it well and bring a customer base that is worth an acquisition.
Building software businesses is a very interesting way to build financial stability and financial security. Unlike so many other things, it has such a massive upside that these downsides - as impactful as they might be - you'll find versions of this in many other occupations that do not guarantee, or at least promise, an exit and an acquisition down the line.
So it's absolutely worth it for me, even though I sometimes feel lonely when I just try to fix my code, even though I wake up to some kind of monitoring email and think, "Oh, come on, this again." Hey, that's just part of the arena. And you can build systems to automate this away, to make it easier, make it better, and you can build processes internally for yourself and the company that you're building to make these things less likely and less impactful.
The Path Forward: Start Slowly
So if you're still here, if you still want to build a software as a service business, go for it. The only thing I would recommend is do it slowly. Do it on the side. Build a software business one hour a day for the first couple weeks. See if you can handle this. See if this fits into your existing lifestyle. And then slowly up it to the point where you're spending most of your time on it.
Get into it easy. I think that's the best way of seeing if this is for you. Don't throw yourself into it - that's just going to freak you out. You have to learn how to deal with these things over time.
Because here's the truth: every challenge I've described, every late-night server crash, every customer rejection, every deprecated dependency - they're not bugs in the system. They're features. They're what make you resilient. They're what make your business defensible. They're what separate the people who build lasting companies from those who give up when things get hard.
The loneliness teaches you self-reliance and drives you to build meaningful connections. The constant fires teach you to build robust systems. The 24/7 responsibility teaches you what truly matters. The resistance to change teaches you empathy and communication. The shifting sands teach you adaptability. The deprecation treadmill keeps you sharp. And owning problems that aren't your fault? That teaches you true leadership.
So yes, never start a software business - unless you're ready to become the kind of person who can handle all of this and still wake up excited about what you're building. Because if you are, there's nothing quite like it.
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