An indie hacker is someone who builds a small internet business, usually software, on their own or with one or two partners, without outside investors, and pays for its growth out of what customers pay. The goal is not a billion-dollar exit. It is a product that earns enough to give its maker a living and a say over their own time.
That is the definition you will find almost everywhere, and it is accurate as far as it goes. What it leaves out is the part I care about, which is why some of these businesses work and most of them never do.
Where the word comes from
The phrase spread through a community of the same name that grew up in the second half of the 2010s, where makers posted their monthly revenue in public and interviewed each other about how they got there. The open numbers mattered. For the first time, a person thinking about building a small software product could see what dozens of real ones earned, how long it took, and what went wrong along the way.
The label stuck because it described something the startup vocabulary had no word for. A startup, in the strict sense, is built to grow very fast, usually with investors’ money, toward a very large outcome or nothing. An indie hacker is playing a different game: smaller, slower, owned, and judged by whether it pays for the life the maker wants.
For the wider picture of the different ways people build on their own, see Building a Business.
What an indie business usually looks like
There is no single shape, but most of them share a few traits.
A narrow product. Not a platform for everyone. A tool that does one job for one kind of customer: invoices for freelance translators, scheduling for small dental practices, a better way to turn podcast audio into show notes.
Recurring revenue. Subscriptions are the common model, because a few hundred customers paying every month add up to something stable. One-off sales, templates, small paid communities and info products show up too, often as a first step.
Very low costs. Hosting, a domain, a few services. No office, no team, often no paid advertising at the start. That is what makes the model possible: the business can be profitable at a size that would be a rounding error for a funded company.
The maker does everything. Building, support, marketing, billing, the website, the emails. This is the part people underestimate.
Why most indie projects fail
I have built two small products and sold both. Neither was large, and both taught me more than anything I read. The lesson I would put first is the least glamorous one: most indie projects do not fail because the product is bad. They fail because nobody was waiting for it.
The usual order goes like this. Someone has an idea, spends three or four months building it, launches it on a couple of directories and forums, gets a small spike of visits, a handful of sign-ups, and then silence. They conclude that marketing is hard, which is true, and that they need to market harder, which is usually wrong. The problem was decided before the first line of code: they built something and then went looking for the people who needed it.
The projects that work tend to start the other way round. There is a group of people who already have a problem, already spend money or time on clumsy ways of solving it, and already gather somewhere the builder can reach. The product is the last step, not the first.
Where the good opportunities come from
The best indie businesses I have seen, mine included, did not come from a flash of inspiration. They came from a change: a new rule, a new technology, a shift in how people behave. Every change of that kind creates new customers overnight, people who suddenly have a problem they did not have last year and no good tool to deal with it.
A new regulation means thousands of small firms need to comply with something they do not understand. A new platform means its earliest users need things the platform does not provide yet. A new habit, like working from home or buying secondhand by default, means new routines and new friction.
Large companies are slow to notice these pockets, and slower to serve them, because each one is too small to matter on their scale. For one person with a laptop, a pocket of a few thousand customers is a business. That gap in size is the indie hacker’s real advantage, more than speed or cost.
The questions worth asking before you build
If you are thinking about an indie project, these are the questions I would want answered first, in this order.
- Who exactly has this problem, and where are they? A real answer names a group you could reach next week, not “small businesses” or “creators”.
- What are they doing about it now? If the answer is “nothing”, be suspicious. People usually do something about problems that matter: a spreadsheet, a freelancer, a workaround.
- Would they pay, and how much? Ask before building. A handful of people willing to pay for an early version tells you more than a thousand sign-ups to a waiting list.
- Can you reach them repeatedly without paying for every visitor? A community, a search term people actually type, a channel you understand. Without one, every customer will cost more than you think.
- Will it still matter in two years? Changes create customers, but some changes fade. The best pockets sit on top of something that is not going away.
Is it worth it?
For the right person, yes. An indie business can give you something a job rarely does: a direct line between the value you create and what you earn, and control over how you spend your days. Some grow into businesses that support a family comfortably. Many stay small and pay for a good part of a life, which is a fine result.
It is also lonely, slow and often frustrating, and the stories you read are the ones that worked. The honest version is that most first projects fail, the second one goes better, and the people who succeed tend to be the ones who kept the cost of each attempt low enough to try again.
If you remember one thing, make it the order. Find the people first. Then build the smallest thing they would pay for. Everything else can be learned on the way.
