Lessons in Vibe-Coding as a PM
How I went from idea to published app in less than a month
Back in 2016, when I was a sophomore in college, I attended a local hackathon with a funny idea: What if there were an app like Tinder where the user was looking for chicken tenders instead of their next close friend? The concept was fun but wasn't quite compelling enough to commit to. Our team (shoutout Wade and Matt) built out a barely-functioning prototype, drove back home, and didn't think about it again for a decade.
Fast forward to January 2026 — I'm in the middle of the holiday season, looking for something to think about between late-night bottles with my daughter, when I see people posting about the power of the latest AI dev tools. I realized this was the perfect opportunity to get hands-on experience and take advantage of my unique skillset: a dev background who's relatively fresh into product management. Then came the hard part: what is the right thing to build?
Tendrrr was the perfect fit. I had the stub of the idea, knew it was feasible, and whipped open the MacBook.
What I came out with on the other side was not just a published app in the App Store in less than a month, but a realization of just how much software development has changed since my last engineering role in 2023. Come along as I break down what I built, what I learned, and where AI still has a ways to go.
The Idea (5 Minutes)
The concept was simple: a Tinder-style swipe interface for discovering nearby chicken tender restaurants. Swipe right to save a spot. Swipe left to skip. That's it.
Part parody, part genuinely useful. The "hot tenders in your area" energy was intentional — I wanted something that would make people laugh but could also actually be used.
PM Insight #1: Constraints make decisions easier. By picking a single, hyper-specific use case (chicken tenders, not "food"), I eliminated hundreds of feature debates before they started. Every design choice had a clear filter: does this help someone find chicken tenders faster?
The Architecture Phase (Days 1–4)
My first instinct was to just start coding. But I'd been a PM long enough to know that's how you end up with a 600-line God Object that does everything poorly.
Instead, I started with a Product Decision Record — a lightweight doc capturing:
- Core user flow (discover → swipe → save → navigate)
- Technical decisions (SwiftUI, local-first data, Yelp API)
- What's in scope vs. out of scope
Then I sketched an architecture before writing a single line of code. The initial codebase had everything crammed into one file — business logic mixed with UI, no separation of concerns. I refactored into a clean MVVM pattern with distinct layers: Models, Services, Repositories, and Features.
PM Insight #2: Technical debt is a product decision. My "quick prototype" would have worked fine for a demo. But I wanted to ship a real product. The extra day spent on architecture saved me at least a week of debugging later.
The API Decision (Day 5)
I needed restaurant data. The options:
| Option | Pros | Cons |
|---|---|---|
| MapKit (Apple) | Free | No photos, no reviews, basic metadata |
| Yelp Fusion | Rich data, great images, 5,000 free calls/day | Rate limits at scale |
| Google Places | Most comprehensive | Expensive and overkill |
I went with Yelp. The free tier was more than enough for launch, and the image quality made the swipe experience feel polished. MapKit stayed as a fallback.
PM Insight #3: Free tiers exist for a reason. For a side project validating a concept, I didn't need the enterprise plan. Build for where you are, not where you hope to be.
The Security Oops (Day 10)
I pushed my code to GitHub. Public repo, nice README, felt good.
Then I realized: my Yelp API key was hardcoded in Config.swift and visible to anyone who looked.
The fix:
- Immediately rotated the API key (the old one was compromised)
- Added
Config.swiftto.gitignore - Created a
Config.swift.exampletemplate for anyone cloning the repo - Made the main repo private
Since GitHub's free tier doesn't support Pages on private repos, I created a separate public repo just for the support site and privacy policy.
PM Insight #4: Security isn't a feature — it's a baseline. Solo, I had to catch my own mistakes. Build security into your workflow: never commit credentials, always use environment variables or config files that stay local.
The App Store Gauntlet (Days 12–18)
Submitting to the App Store for the first time felt like filling out tax forms in a foreign language. Here's what actually mattered:
Required before you can submit:
- Apple Developer account ($99/year — no way around it)
- Privacy policy URL (I used a free generator and hosted on GitHub Pages)
- App icon (1024×1024, no transparency)
- Screenshots for multiple device sizes
Things that seemed easy but weren't automatic:
- Age rating questionnaire (5 minutes, but mandatory)
- Support URL (pointed to my GitHub Pages support site)
- Clear description of what data you collect
Things I worried about that didn't matter:
- Fancy app preview video (didn't need one)
- Elaborate onboarding (kept it simple)
- Perfect copy (approved on my first draft)
PM Insight #5: The App Store review process is predictable if you follow the rules. Apple publishes their guidelines. Read them. Most rejections happen because people skip steps. My submission was approved in under 48 hours.
The Monetization Question (Ongoing)
For a novelty app with maybe a few hundred users, ads would generate ~$3–12/month after integrating an SDK, handling consent flows, and dealing with review headaches. Not worth it.
Instead, I added a simple tip jar — three tiers ($0.99, $4.99, $9.99) using StoreKit 2. Non-invasive, tucked away in Settings, no guilt-tripping copy. If people love the app, they can support it. If not, no friction.
PM Insight #6: Monetization should match your goals. My goal wasn't revenue — it was learning. A tip jar lets fans contribute without compromising the experience. If the app takes off, I can revisit with real data.
What I'd Do Differently
- Build sooner. I've realized a paradigm shift for how to manage the product. In this era of AI development speed, why not build out the prototype and get feedback on that early? It's so much more powerful to have something tangible to discuss, even if it's ugly.
- Build the support infrastructure earlier. Privacy policy, support page, and App Store metadata felt like afterthoughts, but they're required work that's less fun late in the game.
- Test on real devices sooner. The simulator is great for iteration, but location services behave differently on actual hardware. I found bugs in the last 48 hours that should have surfaced earlier.
The Product Manager Perspective
Building Tendrrr reminded me why I moved from engineering into product: the interesting problems aren't the technical ones — they're about understanding what matters.
Should I add filters? Probably not — that's scope creep for a novelty app. Should I support delivery ordering? Maybe — but not until I validate that people actually use the app. Should I spend a week on animations? No — ship the core experience first.
Every feature request I generated for myself went through the same filter: does this help someone find chicken tenders faster? If not, it went to the backlog.
The hardest part wasn't code. It was deciding what not to build.
What's Next
Tendrrr is live. I'm tracking basic metrics (downloads, daily active users) to see if anyone besides me wants this to exist. If there's genuine interest, I'll add features based on actual feedback rather than my assumptions.
If not? I shipped an app to the App Store. I learned SwiftUI, wrestled with App Store Connect, fixed security holes, and remembered what it feels like to build something from scratch.
That was the point.
Key Takeaways for PMs Building Side Projects
- Constraints are your friend. A hyper-specific use case eliminates decisions.
- Architecture isn't overhead. A little structure saves a lot of debugging.
- Free tiers exist. Use them until you have a problem worth paying to solve.
- Security is baseline. Never commit credentials. Rotate keys if you do.
- App Store review is predictable. Follow the guidelines, and you'll be fine.
- Ship the core experience first. Polish is earned, not assumed.
Most importantly: every PM should try to build out at least one idea with AI coding tools. This technology is hard to believe until you try it yourself. Make something small, improve your workflow, build an app that only you would use — because now you can.
Tendrrr is free on the iOS App Store. It finds chicken tender restaurants near you.
Have questions about the process? Find me on LinkedIn or check out the Tendrrr webpage.