What is indie hacking, and how do you become an indie hacker?

What is indie hacking?

Indie hacking is the practice of building your own products and living off what customers pay, without outside investors and without a boss. The word “indie” stresses independence: you choose what to build, how fast to grow and when to stop. The word “hacker” points to doing the building yourself.

The name comes from Indie Hackers, a website and community launched in 2016 by Courtland Allen. When Stripe acquired it in April 2017, TechCrunch described the site as having published dozens of interviews with independent founders, with “independent” generally meaning that money is coming from customers, not VCs or employers. Allen wrote that when he set out to build the site, there were not many places that put profitable online businesses in the spotlight.

That definition is the one to keep in mind. Indie hacking is not tied to a tool, a revenue figure or a business model. It is a way of working: small team, real customers, money first, control kept.

How is an indie hacker different from a startup founder?

Both build companies, but they optimise for different things. A venture-backed founder is aiming at large, fast growth and raises money to get there. An indie hacker is aiming at a business that is profitable and sustainable at a smaller scale, so there is nothing to raise and no investor to answer to.

There is overlap. An indie hacker may go on to raise money or hire a team. A freelancer may build products on the side and move toward indie hacking. The label matters less than the habit of shipping something people pay for.

What do indie hackers build?

Small, focused software and digital products, mostly. Common shapes are web apps with a subscription, browser extensions, templates and starter kits, newsletters, courses and tools aimed at one profession. The product usually does one job for one kind of buyer. SaaS examples such as Plausible, Fathom, Carrd and Tally show what that looks like, and the micro SaaS ideas list gives starting points.

A common pattern is to run several small products at once and let the ones that work grow. Each project is cheap enough to try and abandon, which gives indie hackers more attempts than a company with a large team and a long roadmap.

How do you become an indie hacker?

There is no certificate or application. You become an indie hacker by building something and selling it. This sequence works for most people starting from zero, including those who work a job.

1. Pick a problem you can see. Choose a problem from your job, hobby or daily routine, where you can name the person who has it. The guide to finding app ideas lists places to look, and the ideas on the board are a source of ready-made problems.
2. Check that people pay for the answer today. If people already spend money or hours on workarounds, you have a market. If nobody does anything about it, be careful.
3. Write the product as one sentence. “For [specific person] who [has this problem], this [does one thing].” If you cannot finish it, narrow it.
4. Build the smallest working version. The MVP guide explains how small is small enough. A coding agent can take you from a clear prompt to a first version quickly, but you must read what it makes and test it yourself.
5. Put a price on it early. Charge from the first version, even a small amount. Payment is the clearest proof that someone values the work.
6. Share it where your buyers are. Launching without an audience covers the first customers. Sharing progress as you go, as in building in public, brings feedback and early supporters.
7. Keep what works, drop what does not. Look at what people use and pay for, then do more of that.

For [specific person: job and situation] who [has this problem, and when they last had it],
[product name] is a [type of product] that [does one thing].
Unlike [what they use now], it [one difference they would notice].
I will know it works when [one measurable thing] happens within [number] weeks.

I am a solo builder with [number] hours this weekend. My product is: [paste the one-sentence spec].
Propose a build plan with these parts: (1) the single screen or API endpoint to build first, (2) what to leave out on purpose, (3) the order of work in blocks of at most 90 minutes, (4) three tests that prove the main flow works, (5) how a stranger could try it by Sunday evening.
Do not suggest accounts, dashboards or settings pages unless the main flow cannot work without them.

What does a realistic first year look like?

Expect it to take longer than the stories suggest. Published success stories are the ones that survived, and a lot of attempts earn little or nothing. Plan on keeping your income while you learn, and treat the first year as an apprenticeship in making something people pay for. This is a framework for what to aim at, not a forecast.

The point of this schedule is that each stage ends with evidence. Before you move on, check that the output exists. If a stage produces nothing, that is useful information about the idea, not a personal failing.

What about taxes, contracts and getting paid?

Once you take payment, you are running a business, and the rules depend on where you live and where your customers are. You may need to register the business, report income, charge sales tax or VAT in some places, and publish a privacy policy and terms. Payment providers differ in who handles tax, so read each provider’s own documentation before you choose.

If you also want to protect your name or code, the guide to protecting an app idea explains what copyright and trademarks cover, and the patent guide explains what patents do and do not cover for software ideas.

What habits do indie hackers share?

• They ship small and often. A finished small thing teaches more than an unfinished big one.
• They talk to users. A few real conversations beat weeks of guesses.
• They watch numbers that matter. Repeat use and revenue say more than page views.
• They stay patient. Growth is usually slow before it is fast, and most projects need many attempts.
• They share what they learn. Many write about their progress, which is how the community grew in the first place.

If you have more ideas than time, you do not have to build them all. Post the ones you will not pursue on the board, where another builder may pick them up, and take the next one that fits your skills from the developer tools category or whichever area you know best.