What makes a good Indie Hacker

What makes a good Indie Hacker

Peter Thaleikis

Peter Thaleikis

Engineer. Maker. Open Source Fan. Backpacker

by Peter Thaleikis

Chris McCormick (chr15m) recently announced on Indie Hackers: "Holy heck this is hard" - and rightly so.

Being an indie hacker isn't as simple and easy as it's often presented online. It's not just putting a little MVP together over the weekend, submitting it in on ProductHunt and getting the cash flowing. It's mostly hard work without knowing if you'll end up with a winning product or not. It's having countless doubts about your idea, how to market it and the product itself.

But it's doable and there are people who "win the indie hacker lottery" (lottery is a horrible word for it, btw). There are people building independent business without any external funding or other support every day. In fact, it is more common than CV funded businesses. I'm following stories and reading (too many) books about them. You rarely find them in the places you would expect - it's the little shop owner down the street and the friendly hostel you stayed at on your trip last year. Over time, I've come to see repetitive characteristics and behaviors which seem to enable success. Here are some of the qualities which make it easier (not easy) to be an indie hacker.

Being Scrappy

Without VC funding, a complete team or for that matter any resource in abundance, you naturally have to get creative when it comes to solving problems. You can't give work to employees if you can't afford any and outsourcing much of your work isn't going to be much of an option until you have a stable revenue stream at least. You will need to come up with solutions for problems which make do with what you've already got. Mostly this means you have work within your skill set and time limitations.

This doesn't mean you do everything yourself though. For example, learning to develop mobile apps simply for one project isn't an efficient use of time in most cases - it would rather make sense to find a no-code builder for mobile apps to build a prototype. After the prototype has validated the idea and proved your market, it's time to consider finding a developer as a code founder or contractor - all to get to the goal with your existing skills and resources.


Large and externally-funded businesses usually have to split their focus between their goals and plans and the interests of the investors. For VC-founded companies, this often raises the question of aiming for growth or profit. As Paul Jarvis noted in "Company of One", doing both at the same time is incredibly hard and you have to make a call. You need to either align your goals or find a middle ground - which both take time and energy.

As a super-small just-you business, you've got only one primary goal: turning a profit to make your business sustainable. Nothing more or less. Great growth stories have to wait until you've had a chance to establish your business and ensure you've got a revenue stream to finance from.

You shouldn't have priorities, only a priority.


One aspect indie hackers have a unique advantage in is speed. As a solo-founder, you can change your product and add features at a speed no team could. You have no planning meetings to attend, no communications with team members, and of course no handovers between team members. All these save valuable time when it comes to delivering.

Further enabling your speedy turnarounds, you have in-depth knowledge of your product which allows you to deliver faster even than a team of numerous developers, designers and managers together can achieve.


Innovating is at the core of building an indie business. Without innovation you have to compete on price and price competition usually doesn't leave much in regards to profits. Only large and on-going investments make growth viable in industries facing strong pricing-competition. Not a space for indie hackers really.

But innovation comes at a price: Research and development doesn't come for free and has inherently higher risks compared to doing the same over and over again. Risks aren't what larger organisations want: after all, they usually have strong established interests of stakeholders and investors.

Indie Hackers have the freedom to take risks that aren't acceptable for established companies. You can experiment with a level of freedom which is unique. Use it wisely and find the unique ways to drive customers and profitability.


Unique and authentic connections are an aspect no larger company can even achieve. You are one on one without customers, every time and every day. You have the chance to stand out by being authentic and create in a way people seek it, especially online.

Once a company reaches a certain size and there are dedicated roles, authentic connection is naturally harder, especially with pressure to squeeze out the last bit of growth or profit. So skip formality and bring personality to the table as long as you can.

One interesting way to stand out is being more open. By sharing more insights you build a natural and authentic connection. An open statistics page can be a great start for this.

What does this tell us?

Yes, being an indie hacker is hard, no doubt. But it is worth bringing it into perspective before the Internet, it was much much harder and just 15 years ago pre-Stripe, pre-AWS and pre-GitHub it was much harder than today. I'm not even talking about the computing power in your pocket exceeding the Apollo Missions navigation computers. And there is also the human aspect of it: If it was easy, everyone would do it. It needs to challenge us, otherwise we wouldn't consider it worthy to achieve.

Btw, if you are interested in thoughts like these you might also like to get my newsletter. Just an idea 💪️

Did you like this article?

Besides tones of crap, the web also has lots interesting open-source libraries, actually innovative side-projects and awesome free knowledge. Once in a while, I share these awesome web-findings via email. If this sounds like something you are into, subscribe below:

Subscribe today and get insights soon:

Published under the following tags: