Hey there,
Diogo here. Glad to be writing this post for Product Land!
Today I’m here to write about Indie Hacking. Product Land reached out to me to talk about it after a recent interview for Bitalk, a Portuguese podcast, and the launch of Supercal, my latest venture. In specific, we’ll be talking about one of the main characteristics of indie hacking: speed, and how that shapes product development.
Let’s begin.
What’s an Indie Hacker?
As a clarification for those who’re not aware, an Indie Hacker is traditionally seen as a solo entrepreneur who finds a problem and assembles a software solution to solve it. Hence the hacker. You basically hack away and create something which solves a very niche problem. They also shy away from external funding and VCs.
It has been become more and more popular over the years too, in conjunction with bootstrapped businesses:
More than that, in my opinion being an Indie Hacker is more of a mindset and a way of working. You do things fast. You validate products quickly. And you present the simplest possible solution to a problem. This is more of an enforced constraint than anything else.
And that’s precisely what I want to bring forth today.
The Indie Way to Build Products
I think there’s really some magic to this. I don’t really have a formula to share on how to do a product the Indie way. I think in the end it comes down to:
Building an MVP with an extremely simple tech stack and arbitrary deadlines to force speed.
Finding a distribution strategy for it from the start.
That’s it. I have a few examples to share.
In my most recent project, Supercal, I forced a constraint of shipping this by the 29/February/2024. Mind you, I started in the beginning of December with no coding experience. This quickly ruled out options with higher learning curves such as NextJS or React. I didn’t get them at the start and found them too complicated. Instead I chose a simple stack: PHP, HTML with TailwindCSS, and a bit of Javascript/jQuery for simple front-end operations. My server runs on a Ubuntu server hosted on Digital Ocean running Apache.
This forced me to do things fast. Now that I’ve began testing this with waiting list users, they came across a few bugs and unclear UX. The things they pointed out are the things I fixed first.
In another of my projects, Speedy Audios, I use a Google Sheets as my database. I’m not kidding. Since the whole project is made with no-code (remember fast validation?) this was the simplest way to get it going. This was a good decision because I managed to put this together in a few days to validate it. I didn’t get any customers so in the end I ditched it (more on that later). If I built everything from scratch it would have taken much longer to take something to market. It’s still available if you want to try it out and see how well it works!
And coming from other people, what Pieter Levels did with Nomad List is also a great example. What is now a site making $30,000/Month started out as a crowdsourced Google Sheets.
I think it’s just Parkison’s Law at play. The less time you give yourself the less time it’ll take to put something out there and validate it. You need to make sure you’re solving the problem though. You can’t cut out the essential features otherwise you’ll get false feedback from the market. Keep the core features, delete everything else, and launch it. E.g. if you want to change profile information on Supercal you need to send me an email! There’s no built in way to change it.
What can we call validation?
Money. That’s the realest validation possible.
Everything else can be a mirage. Put if someone is willing to pay you for what you’re building, that’s all you need.
Coming back to Supercal, I actually only decided to build it because I got two early bird customers. They paid 59$ for a lifetime deal, with a money back guarantee in case I didn’t launch by the end of February (more motivation!). I set up a basic homepage. When you clicked on sign up, you would be taken to the Lifetime deal page.
Considering I got a few hundred visits on my site, two customers was enough validation to tell me I was onto something.
Quick note on distribution
This is also super important and often overlooked. When launching a new product it’s to focus on the audience, their problem, and how to solve - while forgetting how you’ll let them know about what you’re building.
This is in my opinion the most important piece of the equation. Without distribution, you’ve got nothing. It’s important to have a clear path to sell from the start. Is it social content? B2B Sales? Social Media content? Built-in referral systems? You need a repeatable system for driving users.
Is the future indie?
I think we’ll see more of this kind of product building in the future. It’s easier to build products, and attention spans are lowering. It’s easier to build, but harder to sell. Spending months building something is a huge risk because in the end it might not solve the need at all, or lack a way to reach the desired audience.
The faster we ship, the faster we learn, the faster we earn. Welcome to the Indie Hacker way!
—
You can follow me on Twitter (X?) for build in public updates on Supercal and my projects -> https://twitter.com/matosdfm
Thank you for reading!
Diogo Matos & The Product Land ⛰️
And also.. get in touch with us if you want to! 👇