90-Day Plan for Solo Developer to Grow Side Project
A 90-day plan for a solo developer to grow a side project from 200 to 10,000 monthly users, focusing on key metrics, distribution channels, and decision gates.
A read-only, creator-approved conversation screened before publication.
A solo developer has 10 hours a week and wants to grow a side project from 200 to 10,000 monthly users. Build the realistic 90-day plan: what to measure weekly, the two channels worth the effort, what to stop building, and the decision gates at day 30/60/90 that say double down or move on. Be honest about what usually kills this attempt.
THE HONEST MATH FIRST 200 to 10,000 is 50x in ~13 weeks. That needs roughly 35% weekly compounding on active users, sustained. At 10 hours a week, one person, that is not a "build more" problem — it is a distribution problem. If you don't have a channel that compounds (referrals, content, SEO), you will not get there. The realistic band for most solo attempts is 3-10x; 50x is the ambitious tail. This plan maximizes your odds of being in that tail, and the gates tell you honestly when you're not. THE WEEKLY RITUAL (90 minutes, same day every week) Measure these five, no more: 1. Weekly active users (WAU) — the number that matters, not signups. 2. Weekly growth rate of WAU. Below ~10%/week sustained = you are not on the 10k curve. 3. New users by source — so you know which of your two channels actually works. 4. Activation rate — % of new users who hit the "aha" moment in their first session. Under 30%: fix onboarding before anything else. 5. Referral invites sent per active user — the leading indicator of whether your loop can compound. Also track the returning-user ratio. If new users don't come back, you're filling a leaky bucket and the growth is fake. THE TWO CHANNELS (the only two) 1. Turn your existing 200 into a referral engine. This is your cheapest, fastest source. Add a shareable artifact — a public result page, a generated report, an embeddable widget — something users want to show others, with a one-click invite. This is not "please share"; it's "here's something you're proud to show." Target: 1 in 5 active users sends an invite per week. 2. One compounding content/SEO channel where your product IS the content. Pick the 5-10 high-intent queries your target users actually search, write one solid piece per week (10 hrs/week = roughly 2-3 hrs per piece), interlink them. SEO compounds monthly, not weekly — expect nothing for 6 weeks, then it starts. If your niche is a community (Reddit, Discord, X), post the same material where the users already are instead of waiting for Google. That's it. One conversion engine (referral), one acquisition engine (content/SEO). Everything else is noise. WHAT TO STOP BUILDING — TODAY - New features. Nobody is leaving because of a missing feature; they're leaving because they never got value or never heard of you. - Settings, dashboards, integrations, polish. Defer all of it. - Anything that takes more than one evening and doesn't touch activation, referral, or the content engine. - The Product Hunt / Show HN "big launch" plan. A spike is not a base; it will not get you to 10k. Your entire build budget for 90 days: onboarding improvements, the shareable artifact, and whatever the content engine needs. That's the whole roadmap. THE DECISION GATES Day 30 — "Is there a signal?" Is any single source producing repeatable signups with time-per-user trending down? Is WAU growth at or above 10%/week? If yes to both: keep going, reallocate all time to the winning channel. If no: stop building entirely, spend 3 straight weeks on the content channel and referral asks before deciding anything else. If there's still zero signal after that, the project does not have compounding potential — this is your first honest exit point. Day 60 — "Is the curve real?" Run the projection: current WAU growth rate extended to day 90. If it lands at 10k, continue exactly as-is. If it lands short, the only acceptable reason to continue is a step-change event you can actually execute (a referral loop that just went viral, a big community post that hit). Otherwise the 10k target is dead — decide now: keep it as a small sustainable project, or wind down. Do not drift to day 90 hoping. Day 90 — "Double down or move on." Hit 10k: double down — the system works, now it's about capacity and monetization. Didn't hit it but growth is still compounding (WAU up week over week, curve still climbing): give it one more 90-day cycle. The project has legs, just not at the speed you wanted. Plateaued (growth flat for 3+ weeks): move on. You have your answer — it's a lifestyle project, not a rocket. That's a legitimate outcome, not a failure. WHAT ACTUALLY KILLS THIS (in order of frequency) 1. Building instead of distributing. The single biggest killer. 10 hrs/week on features is 10 hrs/week not spent getting users. 2. Spraying 10 hours across five channels. Pick two, starve the rest. 3. Ignoring retention. Acquiring users who churn = running in place; your WAU number will lie to you. 4. The big-launch bet. One spike, then nothing, then the founder quits. 5. Invisible progress. SEO and referrals produce nothing for weeks, the founder reads silence as failure and quits right before the curve turns. 6. Treating the 200 as validation. If those 200 came from friends, forums, or a launch spike, they mostly won't refer. Your real product-market signal starts at the referral rate, not the user count. The honest bottom line: at 10 hrs/week, your job for 90 days is not to hit 10,000 users. It's to find out, cheaply and quickly, whether this project compounds at all. The gates above are the mechanism. If it compounds, you'll know by day 60, and 10k becomes a matter of time, not luck. If it doesn't, the gates let you walk away with 10 hours a week of your life intact instead of a year of it.
RELATED SIGNALS
Project Kickoff Plan for Small Software or Creative Project
The conversation produced a detailed project kickoff plan template and a concrete example for a small software project. The plan includes sc
READ TRANSMISSION →
How to Decide Whether a SQL Database Index Will Help a Slow Query
The guide explains how to determine if a SQL database index can improve a slow query by analyzing the execution plan, identifying key factor
READ TRANSMISSION →
Sunk Cost Fallacy and Escalation of Commitment: Historical Examples and Decision
The response explains the sunk cost fallacy and escalation of commitment using the Concorde and Motorola Iridium projects as examples, and p
READ TRANSMISSION →