I spent two months building a macOS tool. Shipped it. Got 23 visitors. Zero paying users.
Not because the code was broken. Not because the design was bad. Because I skipped everything that happens outside the code editor.
Here's the pattern I've watched repeat across dozens of indie products: developer gets an idea, gets excited, starts building, ships after a month, hears crickets, gets confused. The gap is between "idea" and "start building" — at minimum four things get skipped there.
The 4 Things That Get Skipped Before Line 1
1. Does this problem actually exist? Not "do you think it exists" — is someone actively searching for a solution right now?
2. Who already built this? Not just awareness that competitors exist, but a real breakdown of their tech, pricing, and user complaints.
3. Where are your users? Not "on the internet." Specific subreddits, Discord servers, forums, newsletters.
4. Why you? Not feature count. One dimension where you're clearly better.
In a big company, a PM handles this. Product research teams validate it. Solo? All of it lands on you — and developers are wired to jump straight to the code.
My Mistake: Competitive Research After Launch
I built GroAsk — a native macOS menu bar launcher that gets you into Claude Code with a single hotkey (⌥Space). Agent dispatch panel, multi-CLI support, 100% local.
I did competitive research after the product was feature-complete. What I found:
- 10 direct competitors
- The top one (opcode) has 20k+ GitHub stars
- Auto-Claude has 12k+ stars with 73 contributors
- Even the YC-backed Claudia chose AGPL open source
Every single competitor is free and open source. Not one charges a dollar.
If I'd done this research before writing line 1, my design and pricing strategy would have looked completely different.
But here's where competitive research pays off in a non-obvious way: I noticed something in the tech stacks. Every competitor is built on Electron, Tauri, or pure web tech. Not one is native macOS.
That's a real opening:
| Dimension | Electron / Tauri | Native AppKit (GroAsk) |
|---|---|---|
| Launch time | 1–3 seconds | < 0.3 seconds |
| Memory | 200–500 MB | < 50 MB |
| System integration | Limited | Menu bar, global hotkeys, native notifications |
Lesson: competitive research isn't for talking yourself out of building. It's for finding the dimension where you can actually win.
Pick One North Star Metric
The scariest thing about indie products isn't failure. It's not knowing you're failing.
If you're tracking downloads, DAU, retention, conversion rate, and NPS at the same time — you're tracking nothing. When everything matters, nothing matters.
My approach: one north star metric per stage, everything else is context.
Right now I'm tracking GitHub Stars. Reasons:
- Zero friction — no signup, no download required
- Unambiguous — the number is the number
- Social proof — new visitors lower their guard when they see stars
- Real signal — starring means "I think this is useful, might use it later"
Secondary metric: WAU (weekly active users), defined as opened the app 3+ times in the past 7 days. Currently 12.
The stage determines the metric. Cold start: track attention (stars, signups, saves). Growth: track engagement (DAU, retention). Monetization: track revenue (MRR, LTV). One primary metric per stage. Everything else is supporting data.
Distribution Is a Loop, Not a Single Post
Most solo devs think "marketing" means: write a post, share it to a few communities, wait.
I did exactly that. Hit 15+ channels. Then nothing.
What changed it: I started tracking actual referral data. Every download link gets a ?ref=xxx parameter. The site logs where visitors come from.
Two weeks in:
| Channel | Visitors | Share |
|---|---|---|
| GitHub | 34 | 20% |
| Google Search | 35 | 20% |
| X / Twitter | 21 | 13% |
| Appinn (niche software community) | 19 | 11% |
| Eleduck (remote work community) | 13 | 8% |
| W2Solo (indie dev community) | 10 | 6% |
Two decisions came directly from this table:
Cut the low-signal channels. LinkedIn brought 1 visitor. Not worth the time.
Double down on X/Twitter. Claude Code users cluster there. 13% from one social platform signals the high-frequency posting strategy is working. Shifted to 3–5 posts per week of Claude Code workflow content.
Distribution isn't a one-shot. It's a feedback loop: post → track → find what works → concentrate there → post again.
Pricing When All Competitors Are Free
Can you charge when everything similar is free?
I spent a while stuck on this. The math that unstuck me:
Claude Code has millions of users globally (conservative estimate). I need 0.01% of them — roughly 900 people — willing to pay $5/month. That's ~$54K/year.
That reframe moves you off "how do I compete with free" and onto "who are the 900 people and what do they need."
Strategy:
- Free tier: match the best open-source competitor on core features. Don't hide the good stuff.
- Pro tier: things power users actually pay for. Multi-CLI support, advanced monitoring, custom themes.
- Don't compete with free. Compete with "not good enough."
Pricing is never really about the number. It's about: who are you creating value for, what is that value worth to them? If your tool saves someone 10 minutes a day, $5/month is not the conversation.
The 6-Question Checklist
Everything above compresses into six questions. Before you write a line of production code, spend half a day writing actual answers:
1. Who am I solving this for, exactly?
Not "developers." "macOS developers who switch between 3+ Claude Code projects daily and lose context every time." The more specific, the more useful.
2. Who already built this? How good is it?
List 5–10 competitors. Tech stack, pricing, user complaints. Find what users are actively complaining about — that's your opening.
3. What's the one dimension I can win on?
Speed? Native feel? Price? Community? Integration depth? Pick one and go deep, don't spread across all of them.
4. How will I know if this is working?
One north star metric, matched to your current stage. Not five metrics — one.
5. Where are my users? How do I reach them?
Name five specific communities. Track referrals after you post. Cut the low-performers within two weeks.
6. What's the business model?
You don't need a final answer on day one, but you need a hypothesis. Freemium? Subscription? One-time? What's your revenue target, and how many paying users does that require?
These questions don't need perfect answers. Writing them down is already 10x better than "I'll figure it out later."
My product is still in cold-start. The answers are still getting revised. But I'm not "ship and pray" anymore.
If you're building something solo right now — open a doc, spend 30 minutes on these six questions. You'll find that a lot of the fuzzy stuff gets concrete fast.
I'm building GroAsk — a native macOS launcher for Claude Code. If you use Claude Code and want to try it, it's free to start.
What's the business question you wish you'd asked before you started building? Drop it in the comments — I'm curious what others have learned the hard way.
Top comments (0)