One of the most hotly talked about topics in tech right now is starting an indie business. What is an indie business? It's one where you, and maybe a co-founder, attempt to start a business with no investor funding or large external influence. It goes by many names: boot-strapped, solo-founded, self-funded, indie-hackers...etc... and it's pretty hot right now! Which is why we see a proliferation of sites like IndieHackers and posts on Hacker News (frequently making it the front-page). While I think it's an exciting venture to take part of, I don't think it's for everybody. There's a reason that folks seek employment over entrepreneurship, and we often forget these points when we see how "Joe Schmoe" went from an individual-contributor role to making $50k/mo with his side-hustle selling artisanal crayons out of his basement. Also, spoiler-alert, that kind of growth is an outlier, and not something to expect or bet on. A large amount of these run-away success stories are backed by years of failures and experience that catapulted them to where they are now.
So why talk about this? As the sole-developer, founder, and doer of all things at browserless; I wanted to take chance and paint a better picture of what's like to be independent in the technology world. The highs, the lows, and some things you should expect. Which brings me to my first point...
Expect high highs and low lows
One of the things I've personally had a hard time coping with is the absolute roller-coaster ride running a business like this is. I've had post go front-page on Hacker News, been on Codepen's Podcast, and had a top client cancel a subscription in the matter of a few days. If there's one thing that's hard to pull-back in this type of business it's your emotional-investment. Try as you might, things like this affect you emotionally a lot more than they would at a corporate job. Are people going to cancel? Sure. Should you stay awake all-night trying to "fix" or understand why they did? Probably not. Should you feel shame that you're not good-enough? Absolutely not. I think it's important to understand why folks do or don't use your service, but at some point you have to dust off your shoes and move on. There's a myriad of reasons why your product doesn't work for them, and you shouldn't agonize over every cancellation that will come your way. You should also better understand who your customer is as it makes things like churn and messaging a lot easier to deal with.
That said, the experience you'll get far outweigh that in the 9-5 world. Having big, name-brand level customers compliment you on your product is a joy that's really hard to put into words, and also validates your skills and product. I'll never forget one morning when I woke up to a notification that Codepen had signed-up for browserless. I was on cloud 9 the entire day. It's important to hold onto these "small wins" when you're searching through logs at 2AM to understand why your entire system fell over. It's even more important to hold onto these moments when you're experiencing flat-lined growth.
Celebrate often, grieve rarely, and cherish it all.
Be a customer of your product
When I started browserless it was to solve a problem that I experienced as a developer. Even today I still use browserless in other side-projects just because of how it solves a problem (well, at least in my opinion!). I think if you ever get to the point where you can't sympathize with your customers then something has gone terribly, terribly wrong. How are you going to anticipate what the future looks like if you don't have an active part in what's going on today? How are you going to answer the "I signed up for your product, but I'm trying to do XYZ?" when you don't actively use it yourself? One of the best things that could happen for the tech-market is having products that the builders actually use, as they're going to be much more tuned into the needs and demands of that market plus be more receptive.
This solidifies an assumption I've had brewing for a while; and that is systems should be owned by people and not business structures. I've seen this several times in the corporate world, where, due to a restructuring a team or person that owned a project/codebase no longer works on it. Not only do you slow new features and shipments, there's a good chance that whoever "inherits" this application will have no historical context on why it works the way it does. Applications and projects tend to thrive when the people behind them do, and so it can make a lot of sense to be your own maker in the open market.
Build what you'd want to use, and keep using it.
Be prepared to suck at a lot of things, and optimize your surroundings
You know what I'm terrible at: remembering stuff. Finishing a feature request, needing to come back and tackle tech-debt, or looking into ways to expand the business. I suck at keeping this all in context so I heavily rely on tools, my surroundings, and other people to help me be my best self. This can be as simple as appending reminders to emails or asking the recipient to respond if they haven't heard back from you on a future date. This optimizes your surroundings to your benefit, and gives permission to folks to ask about progress without feeling like they're bothering you.
But what if you don't have "learnable" skill like customer-service? Well, first I'd like to dispel the notion that nothing is learnable, but you can also optimize your circumstances here as well. Lots of tools and other forms of automation have helped in this regard, and even something as simple as Intercom can go a long-way in welcoming users. My own hack here is try and craft responses in a manner similar to which I received them. If your user is short and to the point then you should strive to be as well. If they're long-winded, and give a lot of context, it's likely how they approach problems and think about things... and so should you. Obviously you don't want to change the core of what you're saying, but delivering it in the way which you received will go a long way.
Know your weaknesses and remove yourself from those situations as much as possible.
Realize that time is a most crucial asset, likely more so than money
If there's one thing you'll be short on in the early stages it's time. Time is a hard thing to describe properly since there's almost always more of it in the future, but even so it's hard to quantify it like you would money. But I'll be clear in saying that you can earn back borrowed money, but not always borrowed time. When thinking about new features or products I almost always think more about timing and the cost of that time versus what it'll cost in terms of dollars. This is because time is my most precious commodity (especially since I have a family and children). Why is this important to talk about? Well, for one it can be the deciding factor in building your own logging aggregator or paying for one and being done with it. And why wouldn't you pay for one? Especially given that you can't be master of all things so you might as well leverage external services. Plus, riding on what was said above, they'll likely be more passionate and engaged than you are when it comes to logging.
When thinking about time it's also important to think about the next topic that comes from it: tech-debt. This will likely not invoke happy feelings for most of you, since it's largely used in a derogatory sense. I can definitely sympathize with that, as an engineer at heart, as the term still brings about feelings of frustration. However, coming from the other side of it, I can say that it's just like any other leverage mechanism and you should not be afraid to use it when it makes sense. As a case in point, I knew kubernetes was the way to go for doing deployments across a variety of services in a system. However, I make an explicit choice not to start moving over to it in the middle of my launch because it would have put time and release at risk. Both of those factors (time and revenue) were more important to me than my own developer-ergonomics since I knew that I could always come back and fix it later. This is even more important in pre-launch since you don't even know if your product will even generate revenue yet! You can build your ivory castle, but it's still possible that no one will live in it, so don't worry about all the details just yet.
Leverage time, technical-debt, and money to your advantage but continue to learn how to use them and when.
Learn to set deadlines and leverage your many "hats"
Even if it's artificial, deadlines will help you make decisions and get out of the analysis-paralysis mode. I can think of 3 other engineers attempting to push their projects into "making money" mode and have failed to do so yet, even after years of work. One of the common threads is the failure to make decisions and move forward. Situations like "I started in JavaScript, but think this is better done in Go" are extremely expensive changes to make. Moving state into redis, changing database types, or upgrading dependencies are tasks that need to happen, but don't risk launching because of them. There's a reason why we ship first and fast: time is a precious commodity that can't be earned back. Keep moving forward and write a TODO, ideally with a reminder of some kind, to come back and finish the job.
As sole-founder you'll also be responsible for a great many things. While this has downsides, you can manipulate it to your advantage. For instance if I'm not in the mood for writing emails I'll jump into improving my admin UI, or something else that I have energy for. This results in momentum, and momentum can lead to motivation later to finish out those emails. And since you'll be wearing a lot of hats, you can use this to your advantage by switching tasks so that you feel more fresh. At some point you'll likely have to do something you don't want to, but doing a positive thing prior (like writing thank-you emails or any other positive work) can help you feel more motivated to finish dreary tasks.
Be aware of what pushes you forward, and use that when you're facing a hill.
Reach out for help
There's only so much you can do, and since we've established that time is your most crucial asset, you should reach out for help whenever you can. This obviously translates into things like hiring contractors, paying for services, and buying books. However, there's a great deal of bartering that can be done, especially with your clients. For instance, if you're short on case-studies or need alpha testers offer them something that will make it worth their while. That can coupons for products, licenses, or even small gestures like stickers and t-shirts.
There's also a huge community around you. Your specific programming language, framework, and even service providers probably have a following someplace. Many of these same folks have ran, or are running, a business and can kindly point you in the right direction. Asking the right questions here is key, otherwise the advice you receive won't exist or be helpful. Instead of "How can I use Google Analytics?" you might ask "What's your favorite way of monitoring conversions?". Pointed, specific, and even "opinionated" questions tend to get more responses, and are of higher quality. You'll also get more responses if you ask questions that have answers that aren't long-winded. Learning to ask the right question is a skill that's hard to learn, but can be a great asset for your ambitions.
Help has many forms -- learn to ask direct, actionable questions over vague "How do I..." style questions.
Closing
Do I know all the answers to running a business? Definitely not. No one really does and I think that's an important thing to say: we're all just faking it till we make it. Imposter syndrome is a real thing, whether you're an engineer, founder, or writer. Since I more closely relate to programming I'll say that running a business shares a lot of similarities. There's times where you'll need to "reinvent" the wheel because the road you're traversing isn't flat, and there's times where you'll need to leverage other things around you. But don't believe for a minute that you can't do it, it's just a matter of time and effort. I have a strong belief that running a business is as-much of a learned skill as reading is. We all have our stumbling blocks and disadvantages. But disadvantages can be overcome, and when they are overcome that turns into motivation. And once you have a positive feedback loop, it's incredibly hard to stop it!