Same Goals, but a Different Approach
I'm hoping to get some feedback on a different philosophy to indie hacking.
First, let's set the stage. My goal with indie hacking is to eventually diversify my income enough to quit my day job to have time to pursue a larger variety of activities. I'm very inspired by the Tropical MBA.
Common advice around entrepreneurship like Do Things that Don't Scale and sayings like "work on your business, not in it", or "focus on one core problem" etc. Are primarily around building the processes which drive value, and derisking an individual idea.
However, if indie hacking for me is about maximizing enjoyment as defined by pursuit of a variety of activities. I 'ought to have a strategy that integrates well with my ultimate goals. I'm not going to do something unscalable because it would necessitate too much time. That would cause my day job to suffer, increasing risk of ultimate failure – I won't quit until I have an ember to tend to. Similarly focusing on one core problem seems antithetical to my overall goal of spending time a large variety of activities. Why wait until 65 to live my life?
So here is what i'm thinking instead.
What if I build many small, scalable, interrelated bets? I am a builder after all. This allows me to live my dream of pursing a variety of activities – i'm not going to spend 10 years working on a job board.
Scalable, sure that's easy to understand, these need to be low maintenance so I can protect my time, but why interrelated?
I arrived at this by taking inspiration from Jeff Bezos and Amazon. I'm not sure if they explicitly stated this at any point along the way, but Amazon is infamous for taking necessary costs and turning them into revenue streams. For example, AWS, a data center required for amazon.com, turned into one of their most profitable business units. They turned their shipping network into a 3PL service, etc. Amazon is an extremely scalable robust business.
Scalable businesses require investments in automation – appealing to my builder mentality. If those automations are in turn other products with potential revenue streams, then the risk of ultimate failure of my goal goes down. If the original product fails, all is not lost, I can shift focus to products around the operations of the original idea.
An MBA would teach you to cut the fat and double down on your best bet. However, efficiency comes at the cost of resiliency. WTF does an MBA know about how to live life?
Over a longer period of time, I can build small, scalable, interrelated products that let me start living my dream today.
What is your question here?
Hah good question. I'm wondering what people think about the framing around indie hacking? Is this theory internally consistent? Are there missing variables that undermine the premise? Where does this construction fall down? Is this just a terrible idea?
If you want to start something on the side, then start. But, every business takes hard work and effort. All these overnight successes you hear of, were built on years of sleepless nights. There is no shortcut to success (however you define success that is)
@thmsmlr What if you don't build many small, scalable, interrelated bets? You could try to validate bets before you start building. This would save a lot of time in having to build each bet. Instead, just validate with potential customers to understand if you have something viable, before building. This makes the learning loop faster.
I recommend the book "The Mom Test" to learn more about how to validate ideas with potential customers.
Haven't read "The Mom Test", i'll add it to the list. It's referenced a lot.
I think validating the idea is a good call out if the small bets are new to the market. However, if you're building let's say a landscaping company, the validation is done by proxy that there are 10 landscaping companies in my local yellow pages. But it's a good point, and I should probably add a qualifier to the philosophy.
I think the major point i'm trying to get at is that ultimately you have to build, why not build in a way that maximizes the amount of opportunities for diversified income.
For example, suppose you were building an app for PR folks to track down journalists who would write something favorable about their client. To do that, you'd need to scrape all the news publisher websites and create a big database of the topics, journalists, publishers, articles and their sentiment. If validated, you'd need to basically maintain a hugely diverse set of web scrapers. Instead of buying that tool – which would be very expensive – build one for internal use that you can turn around and sell if the journalist tracking app doesn't work out.
A contemporary example of this is Descript they started out as a walking tour app that ended up selling to Bose, but to make making audio walking tours easy, they found the need to build a really powerful audio editing app. The walking tour app didn't work out, but they had descript ready to go and pivot into its own product
This comment was deleted 3 years ago.