How to Build a Passion Project App (And Actually Ship It)
There's a graveyard of half-built apps on developer laptops. Most developers have three or four of them — proof of enthusiasm from two years ago, buried under a folder called old-projects or archive-2024. The idea was good. The motivation was real. Something just stopped.
Building a passion project app is not hard to start. Finishing it is. And finishing well — with real users, a product you're proud of, and maybe some revenue — requires a different approach than most guides admit.
Here's what the developers who actually ship have figured out.
Why Most Passion Projects Stall
The conventional story goes like this: passionate developer has idea, builds nights and weekends, launches to applause. Reality is closer to: developer has idea, builds for three weeks, hits a wall, loses steam, starts something new.
The wall usually shows up around week five or six. Initial excitement burns off, the unsexy infrastructure work begins — auth, billing, error states — and the dopamine from the idea phase is long gone. Developers call this "the boring middle."
Antoine van der Lee, the Dutch iOS developer behind the SwiftLee blog, documented his path out of exactly this trap. He started his indie app work in January 2022 with $80 in Monthly Recurring Revenue. By January 2023 he was at $1,126 MRR. January 2024: $4,512 MRR. March 2024: six figures, and he left his job at WeTransfer after 7.5 years. None of that happened because he felt motivated every day. It happened because he stopped relying on motivation and started relying on structure.
The real problem is the passion trap: assuming your enthusiasm for an idea will carry you through the hard parts. It won't. What does carry you is a product small enough to finish, a user close enough to give you feedback, and a feedback loop tight enough to stay engaged.
Finding an Idea That Doesn't Expire
The best app ideas don't come from brainstorming sessions. They come from annoyance.
Start with problems you personally deal with, then verify that other people share them. Pieter Levels of Nomad List built his most successful products for himself first. When you're your own user, you know within minutes if something breaks, and you can't fake the motivation to fix it.
The mistake most developers make is chasing market size. "The productivity app market is worth billions" means nothing for a solo builder. Micro-niche targeting beats broad categories almost every time. A focus timer built specifically for ADHD remote workers beats "productivity app" the same way a vintage watch newsletter beats a "lifestyle" newsletter: specificity creates the kind of user devotion that drives word-of-mouth.
Before committing to an idea, run it through this checklist:
- Can you describe your target user in one sentence, with a job title and a specific pain point?
- Are there active Reddit threads, Discord servers, or forums where these people already complain about this exact problem?
- Would you use this yourself at least twice a week?
- Can you build a usable version in under eight weeks of part-time work?
If any answer is no, rethink before writing a line of code.
Validate Before You Build Anything
This is the step developers skip most. Building is fun. Validation feels like homework.
But here's the math: solo founders who test with no-code prototypes and waitlist pages typically discover which features nobody cares about before building them, saving months of work. A Figma mockup is not real validation. A landing page that converts 11-13% of visitors into email signups is telling you something real.
The Minimum Lovable Product concept has quietly replaced MVP thinking in most serious indie circles. An MVP (minimum viable product) gives you something testable. An MLP gives you something people actually want to recommend to a friend. The difference sounds subtle. The adoption numbers are not.
| Approach | What you ship | Main risk | Best for |
|---|---|---|---|
| MVP | Bare functionality | High churn, brutal feedback | Pure learning speed |
| MLP | Core value + decent UX | Slightly longer build | Organic word-of-mouth |
| Full product | Everything you planned | Slow and expensive | Rarely necessary |
For passion projects, MLP is almost always the right call. You want users to stick around long enough to give honest feedback, and nobody sticks around for an ugly app that barely works, even in beta.
A concrete first step: post your idea in two or three relevant subreddits as a genuine "does anyone else have this problem?" thread before you build anything. If people ask how to sign up, you have a signal. If nobody responds, you've saved yourself 200 hours.
Scoping the Build
One of the most underrated decisions in a passion project is what you deliberately leave out.
Luca Rossi, who writes the Refactoring newsletter for engineering managers, built a fantasy football app called Fuorigioco in 2018. It flopped commercially. But it taught him React Native and Expo — skills he later used in production at his day job. The app failed by one metric and succeeded by another. Define upfront what "success" means for your first version. Revenue? Learning a new framework? 50 regular users? Each answer leads to a completely different scope.
A healthy first-version scope looks like this:
- Identify the single core action your app enables. One screen, one workflow.
- Build auth, onboarding, and that one workflow. Nothing else.
- Put it in front of 10 people you can contact directly — not strangers on the internet, people who will actually reply.
- Collect feedback before touching the roadmap again.
The number 10 is not arbitrary. Paul Graham has written about this for years: do things that don't scale. Your first users should get an experience that doesn't scale — personal onboarding messages, direct setup help, hand-holding through the first session. That's how you learn what matters before you automate anything.
Staying Motivated Through the Hard Middle
Here's the uncomfortable truth: motivation peaks at the start and drops fast. Projects that ship are not the ones where the developer stayed inspired. They're the ones where the developer built in a way that didn't require feeling inspired.
Tactics that genuinely move the needle:
- Weekly micro-milestones: Instead of "build the dashboard," try "get the user's name to display on the home screen." Small enough to finish in one sitting, satisfying enough to count as a win.
- Build in public: Sharing progress on X (formerly Twitter) or Indie Hackers creates external accountability. Antoine van der Lee grew a 60,000-follower audience partly this way — and the audience became motivation infrastructure.
- Show someone something every two weeks: Scheduling a 15-minute demo with a potential user forces you to have something to show, which forces you to make progress. The writing's on the wall for projects where nobody's watching.
The solo founder burnout rate is sobering — one analysis put it at roughly 54%, compared to about 35% for co-founded teams. You don't need a co-founder. You need someone who asks "how's the app going?" with genuine curiosity and actually waits for an answer.
"The more time you spend building your side project, the more motivation may decline, and at one point you may let it die altogether." — Adapty's indie developer guide
That's not pessimism. It's a planning input. Design your build process around motivation decline, not the assumption that enthusiasm stays constant.
The Launch Strategy That Builds Momentum
Most indie developers treat launch as a single event. The ones with traction treat it as a system.
A three-phase approach used by developers who consistently gain early users:
Phase 1 (pre-launch, four weeks out): Build your waitlist. A landing page with one clear headline and an email capture is enough. Post behind-the-scenes screenshots. Submit to Betalist. The goal is 100-200 email addresses from people who already care.
Phase 2 (launch week): Post to three to five places simultaneously — relevant subreddits, Hacker News (Show HN), ProductHunt, Indie Hackers, and any niche communities your target users frequent. Going viral is not the goal. Getting 50-100 people who care enough to try it is.
Phase 3 (post-launch, ongoing): This is where most apps go silent. Don't. Monthly relaunches, a weekly progress update on social, and SEO-focused content create compound discovery over time. FocusLoop, a straightforward iOS focus timer, reached roughly $300,000 in monthly recurring revenue within 18 months — entirely through organic discovery, no paid advertising.
One pricing mistake to avoid: leaving your app free for too long. Free users give lower-quality feedback because they have no skin in the game. Even $4/month filters for people who are genuinely thinking about whether the app solves their problem.
Growing Into It: From Side Project to Something Bigger
Not every passion project needs to become your full-time income. Worth saying plainly.
Vic Vijayakumar, a Principal Engineer at Twilio, built side projects to prevent burnout, not to replace his salary. The projects fulfilled a creative need that his day job couldn't. That's completely legitimate — not every project needs to end in an acquisition.
But if you're curious what the path to independence looks like, Antoine van der Lee's trajectory is instructive. The critical move was a 4-day work week negotiation with WeTransfer — buying one dedicated day per week without fully quitting. That single day produced what he described as dramatic MRR growth compared to the scattered evenings-and-weekends pace before it. His $80 MRR in January 2022 became $4,512 by January 2024.
The financial principle: don't leave employment until your side income covers your expenses for at least six months. Not one month, not "close enough." The income from a new indie product is lumpy, and your stress level in those early full-time months will be high enough without rent anxiety adding to it.
The macro story for 2025-2026 is that solo builder tooling has never been stronger. Supabase handles your backend. Vercel deploys your frontend in minutes. Stripe processes payments in an afternoon. Maor Shlomo launched Base44 as a side project in early 2025 and reached 300,000 users and $3.5 million in annual recurring revenue within six months — enough to prompt an $80 million acquisition by Wix. That's an outlier. But it shows how much ceiling has opened up for solo builders willing to work a specific problem with real focus.
Bottom Line
Building a passion project for an app is not about finding the perfect idea or the perfect moment. It's about building small enough to finish, validating early enough to learn, and creating systems that outlast initial excitement.
- Validate before writing code: one Reddit thread asking "does anyone else have this problem?" can save 200 hours of building something nobody wants.
- Scope ruthlessly: ship one workflow, give it to 10 real people, collect feedback before touching the roadmap.
- Design for motivation decline: micro-milestones and bi-weekly demos keep momentum going when enthusiasm drops.
- Treat launch as a system: pre-launch waitlist, multi-channel launch week, steady post-launch visibility — not a single big announcement.
- Charge earlier than feels right: even $4/month validates that people see real value and generates meaningful feedback.
The graveyard of half-built apps doesn't need another entry. Start smaller than you think you should, ship sooner than feels comfortable, and let real users tell you what to build next.
Frequently Asked Questions
Do I need a co-founder to build a passion project app?
No — most successful indie apps are solo projects. What you do need is accountability. An informal build-in-public audience, a developer friend who checks in weekly, or a community like Indie Hackers provides enough social pressure to keep projects moving without requiring a formal co-founder relationship.
How do I know if my app idea is worth pursuing?
Post it in two or three relevant subreddits or forums as a genuine question before writing any code. If people ask how to sign up, that's a meaningful signal. If you get no engagement despite a well-written post, that's data too. The clearest signal of all: would you pay for this yourself?
Is it realistic to turn a passion project app into full-time income?
Possible, but rarely quick. Antoine van der Lee took about two years from $80 MRR to six-figure income. Developers who make it typically run multiple revenue streams (app subscriptions plus content plus sponsorships) and treat marketing as seriously as coding. Expecting one app launch to produce passive income is the most common planning error.
What's the real difference between MVP and MLP?
A Minimum Viable Product is the smallest thing you can ship that functions. A Minimum Lovable Product is the smallest thing you can ship that people actually enjoy using and tell others about. For passion projects, MLP wins: early users who have a good experience become your first marketing channel, and word-of-mouth is the only growth channel most solo developers can realistically count on.
When should I start charging for my app?
Earlier than feels comfortable. Even a $4-5/month price point filters for users who are genuinely evaluating whether your app solves their problem. Free users are harder to learn from because they have nothing at stake. Early monetization also answers the single most important question a solo developer faces: will anyone pay?
How do I prevent burning out halfway through a passion project?
Break your roadmap into two-to-three week sprints with specific, completable deliverables. Schedule a demo with someone real every two weeks — the social obligation forces visible progress. And give yourself explicit permission to ship something imperfect. Most mid-project burnout comes from perfectionism, not overwork: the inability to call a feature "good enough" keeps developers in an exhausting loop of refinement that never ships.
