What 150 downloads and zero feedback taught me about product prioritization.
Building when nobody’s talking and you’re just guessing at what matters.
150 people downloaded Leafed in the first month.
Zero reviews. Zero support tips. Zero feature requests. Zero emails asking “can you add this?”
Just App Store metrics showing downloads happened. No attribution data. No way to know who they were or why they showed up.
Users who won’t tell you what’s wrong, but also haven’t left. So how do you decide what to build next?
Your prioritization framework shifts entirely.
I learned this by rebuilding Leafed over the past month. No user panels. No A/B tests. Just App Store silence and decisions about what to build anyway.
Three phases emerged, not from a plan, but from reality forcing my hand.
When users won’t talk, build in three phases
Phase 1: Fix what you didn’t plan for
I built Leafed’s initial screens by looking at other apps, researching best practices, and letting Claude and ChatGPT help with implementation. The LLMs prioritized functionality over aesthetics, which meant I shipped something that worked but looked inconsistent.
The feedback I did get: “Doesn’t feel like modern design.”
Clean, yes. Cohesive, no.
I needed a design system. Not eventually. Now.
The rewrite meant touching 30+ active screens. I used ChatGPT to orchestrate the plan, then Cursor’s Claude Opus for detailed planning and Cursor Composer for fast execution. One week of work, including testing.
The most frustrating part wasn’t the initial fixes. It was regression testing every user flow to make sure nothing broke. Even with a plan, some elements, like headers, needed special focus to work right.
Planning infrastructure early: the difference between touching three files or 30.
If you’re building with AI and you think you might scale, research what a design system plan looks like before you build screen number one. Your future self will thank you.
Phase 2: Build mechanisms before you need them
I wanted to add payments for months, but couldn’t get it working. Then I found RevenueCat - widely used, relatively easy to integrate.
It took a couple of days, mostly because testing on both the Apple App Store and the Google Play Store was tricky. Set up the infrastructure. Verified it worked. Launched it.
Revenue generated so far: $0.
I’d be lying if I said that doesn’t sting a little. When something doesn’t explode - when you’re at 150 downloads and zero revenue - it’s tough to feel like the time is well spent.
But Leafed is a hobby project. A passion project about building, not just about shipping a successful app. The mechanism exists now. When someone finds Leafed sticky enough to support indie dev work, they can. Can’t get paid without the option to pay.
The expense is low. I’m learning database architecture, API design, and mobile development patterns. Skills that compound into other things I can build.
I’ll slowly reduce the time spent if no support comes in after a few months. But until then, while other things are in a holding pattern, I’m using Leafed to plan out what’s next with these new skill sets.
Phase 3: Match table stakes, then find your gap
Without feedback, you’re guessing at what matters. So I started with what users expect.
I added a bottom navigation bar. Took a couple of hours because I already had the infrastructure in place. It solved a data persistence problem I was having across screens. Most apps have a bottom nav. Users expect it. Makes the app feel legitimate.
Then I built my own database for indie books.
Why? No public database of indie-focused books exists. Sites that aggregate indie author submissions don’t share their data—they want you coming back to their platform. So I built from the ground up: database, APIs, and real-time mobile calls.
More work than using an existing book API. But I got feedback that focusing on indie author marketing would be huge. Plus, I learned database infrastructure I could potentially offer as an API service later.
Match users' expectations, then lean into what makes you different. For Leafed: indie book focus, no tracking, features built as learning experiments that benefit users.
AppScreens made creating App Store screenshots painless (click to check them out). Generating professional mockups without wrestling with Figma templates for hours was worth the cost alone.
Once feature-complete (mostly there now), marketing targets that gap.
Those three phases weren’t a strategy. They were responding to what broke.
Prioritizing in silence
Fix what’s broken. Add what’s missing. Match what users expect.
But going through them revealed something: when users won’t talk, your prioritization criteria flip. You’re not optimizing for engagement signals or feature requests. You’re making calls about what infrastructure to build before you know if you’ll need it.
Four principles emerged from making those calls:
1. Infrastructure first if you plan to scale
Design systems, payment mechanisms, and data architecture.
The cost of doing it wrong: 30+ screens to fix later.
Rule: If you’ll touch it 10+ times, build it properly once.
2. Table stakes before differentiation
Bottom navigation bars, expected features, things users assume should exist.
You can’t win on gaps if you’re missing basics.
Rule: Users won’t tell you what they expect - they’ll bounce.
3. Mechanisms before you need them
Payment infrastructure at $0 revenue.
Analytics before scale. Can’t optimize what you can’t measure.
Rule: Optionality has value even at zero usage.
4. Find your gap, then market it
Once you match competitors, your positioning highlights what you do differently.
For Leafed: indie book focus, no tracking, features built with user benefit in mind.
Rule: Differentiation without parity is just being different, not better.
Most product advice assumes feedback exists. User interviews. Analytics dashboards. Support tickets telling you what’s broken.
Early-stage building doesn’t work that way. You’re making infrastructure bets, matching invisible expectations, and building mechanisms for a future that might not come.
This is the gap between “build fast and learn” advice and the reality of building when learning requires users who won’t talk.
Building before the tipping point
AI can analyze user feedback when it exists. It can’t make judgment calls when the feedback is 150 downloads and silence.
Product judgment under uncertainty compounds in ways execution skills don't. You’re reading signals in what users don’t do. Making bets on infrastructure before you need it. Choosing what not to build when every option feels equally valid.
This is the PM skill that matters before product-market fit: deciding what to build when nobody’s telling you what they want. The companies cutting product teams are betting AI can make those calls. They’re about to learn the difference between generating solutions and knowing which problems to solve.
Skills compound. Data doesn’t exist yet. Build anyway.
Until next week,
Mike Watson @ Product Party
P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.
You have learned a lot from this experience. Thank you for sharing the stories!