Part 3: What building a mobile app taught me about being a better product person.
Both apps went live within a week. The bookshelf scanner I cut in Part 1 is back. And I finally understand why developers say, "it's not that simple."
Two weeks ago, I was on day 13 of Google’s mandatory testing period, wondering if I’d actually get Leafed into production. Last week, I walked through the submission gauntlet: the 14-day requirement, the essay questions, the platform differences.
This week - Both apps are live. Apple approved in 48 hours after I fixed their feedback. Google approved two days after I submitted. You can find your download for either version at leafed.app (which… was also vibe-coded of course).
But the story doesn’t end with approval. It starts there.
Apple moves fast when you listen to their feedback.
Sunday night: Submitted to Apple. Monday night: Rejected.
Apple flagged my “Buy Me a Coffee” button because it looked like it should be an in-app purchase. They were right. From a UX consistency standpoint, a donation button in that placement creates user confusion across their platform.
I removed it. Resubmitted Tuesday night. Approved Wednesday afternoon.
Total turnaround from rejection to approval: 48 hours.
That’s the thing about Apple’s process. It’s fast, but they’re incredibly particular about user perception and platform consistency.
Not arbitrary pickiness. Thoughtful curation.
Google’s process is thorough but straightforward.
After the 14-day testing window closed, I submitted my production request on Wednesday morning. Approved Friday.
Google’s information release is more tedious than Apple’s, but once you have your testing evidence documented (which you should after living through 14 days of coordinated human engagement), the process is straightforward.
Different philosophy than Apple. Not better or worse. Just different.
Both apps went live within the same week. Different approaches. Same outcome.
The feature I cut in Part 1 is back (and I’m nervous about it).
Remember the bookshelf scanner I built and cut because ML Kit couldn’t handle inconsistent book cover formatting?
I kept thinking about it.
Used Perplexity to dig through alternative approaches. Researched how other apps solved this problem. Found different implementations. Tested a few solutions.
Eventually got it working. Not with the original approach, but something different that handles the formatting inconsistencies better. I’m not sharing the specific tech yet, but the point is: cutting a feature doesn’t mean giving up on it.
Now it’s live in the app. And I’m watching usage carefully.
I added per-user caps to manage usage costs while I figure out if people actually want this feature. Right now, I’m focused on getting users to try it rather than optimizing for monetization. But if this thing gets real traction, those caps give me room to add paid tiers later without eating costs I can’t sustain.
That’s product thinking, not just building.
My workflow made this possible.
People keep asking how I built this as a non-developer. The answer isn’t “AI writes code for you.” It’s more nuanced.
Research deeply. When stuck, I used Perplexity to dig through obscure GitHub repos, alternative libraries, and how other developers solved similar problems.
Feed context to Cursor. Not just “build this feature” but “here’s what I found, here’s the approach, here’s what didn’t work before.”
Experiment in isolation. I’d spin up 3 versions of the same feature using different approaches. Push each one. Test them. See which works best. Remove the rest. Easy to do with vibe coding, impossible with traditional development.
Test fast. Expo Go for quick iteration, TestFlight for Apple-specific testing.
Make product decisions. When something worked, I decided if it should ship.
The combination of research tools (Perplexity), implementation tools (Cursor), near-instant testing for most features (Expo Go), rapid experimentation, and product judgment made this possible. Not any single tool. The workflow.
What this taught me about product work that I couldn’t learn any other way.
Building Leafed changed how I think about product conversations.
When someone says, “Can we add this feature quickly?” I now think about deployment pipelines, platform reviews, and usage costs instead of just saying “probably.” When developers call something hard, I believe them because I’ve watched “simple” fixes take a week of research and multiple failed attempts.
When stakeholders ask about A/B testing post-launch, I understand why mobile platforms make that nearly impossible. When someone says “API costs should be minimal,” I think about the per-user caps I set before I had any users, because unit economics matter from day one.
I’m not a developer and don’t want to become one, but I understand their constraints differently now. When they push back on timelines or talk about technical debt, I get it because I’ve made those same tradeoff decisions.
This isn’t about learning to code. It’s about understanding constraints firsthand by building something real, shipping it to actual platforms, and managing real costs.
Tools like Cursor and Perplexity make building accessible, but they don’t replace developers. They close the gap enough that product people can experience the process viscerally and develop the skills that actually matter: research, synthesis, pattern recognition, and product judgment.
AI can’t decide what to build, when to cut, when to iterate, or when to ship. That’s still human work.
What’s next for Leafed?
Both apps are live. I’m just starting to market it. No real traction data yet because I literally just launched.
I’ll keep iterating based on what I learn from actual users (if I get any). The bookshelf scanner is the feature I’m most excited about, but it’s also the one I’m most nervous about because of usage costs.
Maybe people will love it. Maybe they’ll never use it. Maybe I’ll need to add paid tiers. Maybe it’ll just sit there as a free app that a few people find useful.
Either way, I accomplished what I set out to do: understand mobile development end-to-end by actually shipping something real.
The goal wasn’t downloads. It was education. And that goal is complete.
Why you should build something.
If you’re a product person who wants to better understand technical constraints, build something real, and ship it. Not to become a developer, but to become a better product person.
The tools exist. Cursor can help you build, Perplexity can help you research, React Native and Expo let you target multiple platforms. The barrier isn’t technical skill, but deciding to start and committing to finish.
I spent around $175 in year-one costs. What I got back was worth more: understanding that changes every technical conversation I’ll have for the rest of my career.
Download Leafed at leafed.app. Try the bookshelf scanner. See what’s possible when product people stop theorizing and start shipping.
Until next week,
Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.