I spent two months building a macOS tool, shipped it to communities, got 23 visitors, and zero paying users.
It wasn't the code. It wasn't the design. I skipped almost everything that happens before you write the first line.
The trap is obvious in hindsight: developers are good at building things, so they default to building. Business thinking gets pushed to "later." Later never comes until you're staring at a quiet launch and wondering what went wrong.
The Path Most Solo Devs Take
Idea → excitement → build → ship → silence → confusion.
The gap is between "idea" and "build." At minimum, four questions get skipped:
- Does this problem actually exist? Not "I think it exists" — does anyone search for a solution?
- Has someone already built this? And how well?
- Where are your users, exactly? Not "the internet" — which specific communities, forums, channels?
- Why you? Not "more features" — which one dimension can you genuinely win on?
In a company, product managers answer these. A product research team validates them. Solo, it's all on you.
My Real Example: All Competitors Were Free, I Still Wanted to Charge
I built GroAsk — a native macOS menu bar launcher that gets you to Claude Code with one hotkey.
I built the product first, then did the competitive research. I found 10 competitors. The most deflating data point: every single one was free and open source. Not one charged anything.
The top competitor had 20k GitHub stars. Another had 12k. Even a YC-backed product went AGPL open source.
If I'd done this research before writing a single line of code, my entire product strategy would have been different.
But competitive research isn't only bad news. I looked at their tech stacks: every competitor was Electron, Tauri, or web-based. Not one was a native macOS app.
That gap matters. Native AppKit vs Electron means:
- Launch time: < 0.3s vs 1–3 seconds
- Memory: < 50 MB vs 200–500 MB
- System integration: global hotkeys, menu bar persistence, native notifications that actually work
The lesson: competitor analysis isn't about talking yourself out of building. It's about finding where you can genuinely beat them.
Pick One North Star Metric
The thing solo developers fear most isn't failure. It's not knowing they're failing.
When you track everything — downloads, DAU, retention, paid conversion, NPS — you're effectively tracking nothing. The numbers don't add up to a decision.
I picked one north star metric: GitHub Stars.
Why stars, not something more "business-y"?
- Zero friction: no signup, no download, one click
- Unambiguous: the number is the number
- Social proof: visible stars lower the decision barrier for the next visitor
- Signal of real interest: someone thought "this looks useful"
My supplemental metric is WAU — weekly active users defined as "opened the app at least 3 times in the last 7 days." Currently 12.
The right north star metric changes with your stage. Cold start: measure attention (stars, saves, signups). Growth phase: measure engagement (DAU, retention). Monetization phase: measure revenue (MRR, LTV). One primary metric per stage. Everything else is context.
Distribution Is a Feedback Loop, Not a One-Time Event
Most solo devs think "marketing" means: write a post, submit to communities, wait.
I did that. Posted to a dozen platforms, then waited. Nothing clear came back.
Then I added ?ref=xxx tracking parameters to every link and watched referral data for two weeks. Here's what came back:
| 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 from this table.
Cut the losers. LinkedIn sent 1 visitor. Other platforms were near zero. I stopped posting there entirely and put that time into the top 5 channels.
Double down on X. Claude Code users are heavily concentrated on X. 13% of traffic from one social platform — that's a signal. I shifted to posting 3–5 short Claude Code workflow tips per week.
Distribution is a loop with feedback: ship content → track sources → identify what works → concentrate there → repeat.
The Pricing Question When Competitors Are All Free
Can you charge when everyone else is free?
I sat with that question for a while. Then I did the math.
Conservative estimate: Claude Code has millions of active users globally. I need 0.01% of them — roughly 900 people — willing to pay $5/month. That's $54k annual revenue.
That reframe pulled me out of the "compete on free" spiral. The strategy became:
- Free tier as good as the best open source alternative — no hiding core functionality
- Pro tier with genuine differentiation — multi-CLI support, advanced monitoring, things heavy users actually need
- Don't compete with free. Compete with "not good enough."
Pricing isn't about how much to charge. It's about who you're creating value for, what that value is, and what it's worth to them.
If your tool saves someone 10 minutes a day, $5/month is a rounding error in their decision-making.
The 6-Question Business Checklist
These are the questions I wish I'd written down before I wrote any code. They're not perfect — they'll change as you learn more. But writing them down at all is 10x better than "I'll figure it out later."
1. Who am I solving this for, specifically?
Not "developers." Try "macOS users who run Claude Code across 3+ projects daily and keep losing context switching between terminals."
2. What already exists? How good is it?
List 5–10 competitors. Look at their tech stack, pricing, and user complaints. The complaints are your opportunity.
3. Which one dimension can I win on?
Don't try to win everywhere. Speed? UX? Price? Community? Niche integration? Pick one and go deep.
4. How will I know if I'm going in the right direction?
One north star metric. Stage-appropriate. Everything else is supplemental.
5. Where are my users, and how do I reach them?
Name 5 specific communities. Post there. Track referrals. Cut what doesn't work within two weeks.
6. What's the business model?
You don't need the final answer on day one. You need a hypothesis. Freemium? Subscription? One-time? What's the target revenue? How many paying users does that require?
The answers will be wrong at first. That's fine. Writing them down forces clarity that "figuring it out later" never delivers.
I'm still in cold start. My answers to these questions are still shifting. But I'm not shipping into the void and hoping anymore — I know which numbers matter, which channels work, and where the actual opportunity is.
If you're building something right now: open a document, set a 30-minute timer, and write your answers to these 6 questions. You'll be surprised how much gets clearer.
The author uses Claude Code daily to build GroAsk — a native macOS AI workbench. ⌥Space to reach all your AIs, with real-time monitoring of multiple Claude Code terminal states. If you're using Claude Code, give it a try.