The Indie Hacker Complete App Building Playbook

Indie hacking is building a profitable software product without outside funding, usually as a solo founder or a very small team. The appeal is clear: full ownership, full control, and the ability to work on your own terms. The challenge is equally clear: you are doing everything yourself.

This playbook covers the entire journey from choosing an idea to getting your first paying customer. No theory. No fluff. Just the steps that work.

## Step 1: Choose an idea you can finish

The number one reason indie hackers fail is choosing ideas that are too big. A social network takes years to build. A feature-rich SaaS with integrations across 20 platforms takes months just to scope. You need an idea you can ship in 4-8 weeks as a solo builder.

Good indie hacker ideas share three traits:

**Narrow audience.** "Freelancers" is too broad. "Freelance copywriters who manage more than 5 clients" is narrow enough. Narrow audiences are easier to find, easier to market to, and more willing to pay for tools built specifically for them.

**Existing spending.** Your target users already pay for tools that sort of solve their problem. You are not creating a new category. You are serving an existing need better than the current options.

**Buildable scope.** Can you describe the app in 5-8 screens? If you need a whiteboard to map the feature set, it is too big. Start smaller. You can always add features after launch.

Browse our [Ideas Library](/ideas) for validated ideas that match these criteria. Every idea is scored on solo-builder feasibility as part of our [100-point rubric](/how-it-works).

## Step 2: Validate in 48 hours

Validation does not need to take weeks. Here is the 48-hour version:

**Hour 1-4:** Search Reddit, Indie Hackers, and Hacker News for people discussing the problem. Take screenshots of every relevant complaint, question, or feature request.

**Hour 5-8:** Read 1-star and 2-star reviews for competing apps. Note the patterns. What do people hate? What is missing?

**Hour 9-16:** DM 10 people from those forum threads. Ask about their problem, not your solution. Listen for intensity. Casual frustration is not demand. Passionate frustration is.

**Hour 17-24:** Check willingness to pay. Look at what competitors charge. Ask your DM contacts what they currently spend on solving this problem.

**Hour 25-48:** Build a simple landing page (Carrd, Framer, or a Next.js template). Describe the problem and your proposed solution. Add an email signup form. Share it in 2-3 relevant communities. If you get signups without paid promotion, the demand is real.

If you cannot find evidence of demand in 48 hours, move on. The idea might work, but the validation difficulty is a warning sign about distribution difficulty later.

## Step 3: Scope ruthlessly

Take your validated idea and cut it in half. Then cut it in half again. The feature list for v1 should make you uncomfortable with how small it is.

Here is a scoping exercise: write down every feature you want. Now circle the 3 features that are most different from existing solutions. Those 3 features are your v1. Everything else goes on a "post-launch" list.

Your v1 needs to do three things well: 1. Solve the core problem (the reason someone downloads the app) 2. Let users sign up and manage their account 3. Accept payment

That is it. No onboarding tours. No social sharing. No analytics dashboards. Those come later, after you know people will pay.

## Step 4: Build fast

As a solo builder, your biggest risk is spending months building and never launching. Speed is survival.

Pick your tools and stick with them. Do not evaluate 15 frameworks. Here is a stack that works for mobile apps in 2026:

- **Framework:** React Native with Expo - **Language:** TypeScript - **Backend:** Supabase (auth, database, edge functions) - **Payments:** RevenueCat (handles both iOS and Android subscriptions) - **Analytics:** PostHog (free tier is generous) - **Deployment:** EAS Build and Submit

If you want the build handled for you, [Goodspeed's pipeline](/features/building) generates production-ready apps on this exact stack. You get working code in days instead of weeks.

Set a launch date before you start building. Write it on a sticky note and put it on your monitor. Every feature request, every design tweak, every "quick improvement" gets evaluated against that date. Does it need to be in v1? Or can it wait until v2?

## Step 5: Launch without fanfare

Your first launch is not a product launch. It is a learning exercise. You are putting something in front of real users to find out what works, what breaks, and what people actually want.

**Week 1: Soft launch.** Share with 10-20 people from your validation step. Give them the app for free. Ask for honest feedback. Fix the bugs they find. Do not fix the features they request (yet). Just fix what is broken.

**Week 2: Community launch.** Post in the 2-3 communities where your target audience hangs out. Not as a marketing post. As a story. "I built this because I had [problem]. Here is what it does. I would love feedback." Be genuine. Communities can smell marketing from a mile away.

**Week 3: Wider launch.** Product Hunt, Show HN, relevant subreddits, and direct outreach to people who match your target audience. This is your push for initial traction.

Track everything. Onboarding completion rate. Feature usage. Where people drop off. What they complain about. This data shapes your roadmap for the next three months.

## Step 6: Get to your first paying customer

The first dollar is the hardest and the most important. It validates that someone will exchange real money for your product.

If you launched with a free tier, email your most active users and offer them early access to the premium features at a discount. Their usage data tells you who is most likely to convert.

If you launched with a trial, focus on trial-to-paid conversion. Watch where users are in the trial when they convert versus when they drop off. Adjust the trial length, the features included, and the upgrade prompts based on this data.

If nobody converts in the first month, do not panic. But do investigate. Talk to users who signed up but did not pay. Ask them why. The answer is either a pricing problem, a value problem, or an audience problem. Each one has a different fix.

## Step 7: Build in public

The indie hacker community is your distribution channel. Building in public, sharing your progress, numbers, wins, and failures, attracts attention, builds trust, and creates a flywheel of users who root for your success.

Share your weekly metrics on Twitter/X. Write a monthly update on Indie Hackers. Post progress screenshots on Reddit. Be honest about what is working and what is not. The transparency attracts people who want to support solo builders.

Building in public is not about bragging. It is about accountability and connection. The founders who share openly tend to get more help, more feedback, and more users than those who build in silence.

## The indie hacker advantage

You have something that funded startups do not: speed and independence. You can ship a feature today that a larger company would spend two weeks in meetings discussing. You can pivot overnight if the data says you should. You can talk to every single user personally.

These advantages only work if you use them. Move fast. Talk to users. Ship constantly. That is the playbook. Everything else is a distraction.

Start with a [validated idea](/ideas), build it on a [proven stack](/features/building), and launch before you feel ready. Your future customers are waiting.