7 Things Nobody Warns You About Launching Your First Vibe Coding App
What nobody warns you about launching your first vibe coding app: 7 real lessons from hosting hell across 5 platforms, packaging failures, and the 10/90 rule.
Have you ever received promotions for quirky apps and wondered how they came to life?
Or maybe you’ve been curious about the inner workings of their customer service?
With the rise of AI, you might think creating and launching an app has become a breeze. That’s exactly what I thought before diving headfirst into my first product — a simple image-finding app. The ideas started from my very first AI learning projects, and with zero experience, I decided to take the plunge.
The ideas started from this very article carrying out AI learning processes; and with zero experience, I decided to take the plunge.
[
Build to Launch
Lost in Photos? My First GenAI Project Finds Them Fast
Hey there! 👋 Welcome to my first GenAI 30-Project Challenge…
Read more
2 years ago · 6 likes · 1 comment · Jenny Ouyang
Here’s my story of how a quick project turned into a full-fledged learning experience, complete with unexpected challenges, sleepless nights, and a newfound respect for app developers.
Hi, I’m Jenny — I build AI systems and teach people to do the same. This article was originally published on Medium in January 2025, right after I launched my first vibe coding app. The chaos, the hosting hell, the emotions — all unedited. At the end, I’ve added what I’d do differently today with Claude Code.
If you’re new here, these three are worth reading first:
How to Start Vibe Coding: The Roadmap Nobody Gave You — read this before you build anything
8 Vibe Coding Mistakes That Break Production — the traps this article documents, named and solved
I Made a Note-Generating App to Free My Brain — what I built next, and how much smoother it went
From Concept to MVP: The Smooth Beginning
Creating the app’s core feature was fast, fun, and immensely rewarding. My goal was simple: build a tool to help me quickly search for images in my folders. I worked on a couple of articles to set up the baseline and, before I knew it, I had a working MVP.
[
Build to Launch
Quick Search of Hidden Photos With Optimization Approaches
Have you ever found yourself drowning in a sea of unorganized photos? I know I have…
Read more
2 years ago · 7 likes · 2 comments · Jenny Ouyang
Soon after sharing it, people started asking, “Is it available for me to try it out?” That’s when it hit me — why not make this app available for everyone? Excited by the prospect, I decided to launch it.
Little did I know, the real work was just beginning.
Beyond Building: The Realities of Launch Prep
Once I committed to launching, I realized there was more to consider than I had imagined:
User Registration: Should I allow Google sign-ins or stick to email? I initially offered both but eventually simplified it to email registration.
Monetization: How do I manage subscriptions? I wanted to provide a limited-time free trial and tiered plans — monthly, yearly, and lifetime.
User Communication: Keeping an open line for feedback and improvement was non-negotiable.
I explored tools like Shipfast and boilerplate templates to speed things up. That was a few days of investigation, comparison, and hands-on trial. I ultimately decided to build my setup from scratch for three key reasons:
Hands-On Learning: Pre-built templates felt like shortcuts. I wanted to understand the fundamentals.
Dependency Conflicts: Many templates had unresolved issues, creating more work than starting from scratch.
Framework Mismatch: The templates didn’t align with my app’s framework, making customization a nightmare.
Every feature turned into a crash course in user experience: handling forgotten passwords, enabling subscriptions, managing logouts, and even adding gifting options. With each addition, the scope of work expanded, driving home the reality that launching an app means addressing user needs from every angle.
Concepts like email rerouting and hosting, which might seem routine to seasoned techies, felt like new adventures to me. I marvelled at Stripe’s thoughtful testing mode and tackled password hashing and Google login for the first time. Each task opened a new door, satisfying my curiosity and fueling my excitement.
I was so confident my MVP would be ready before 2025 — until I ran headfirst into the unexpected time sinks.
The Unexpected Time Sinks
If you break the product process into three steps — building the MVP, adding the extras, and hosting it online — you might assume the MVP would take the most time.
The rest? Simple, right? Just toss in a few templates for user registration, handle some basic features, and click a couple of buttons to host.
Soon I realized my assumptions were not even close. The time distribution is almost the exact opposite of what you expect.
Lesson 1: Cheap shared hosting will fail your ML app
Initially, I thought cheap hosting services like Namecheap or GoDaddy would suffice. Boy, was I wrong.
After multiple crashes and hours of debugging, I discovered these services couldn’t handle the app’s heavy dependencies, like Torch and Transformer. Even after reaching out to support and experimenting with Oracle Cloud, I hit roadblock after roadblock.
I went through a maddening cycle: activating domains, transferring domains, updating hosting specs, setting up email services, and configuring environments — across Namecheap, GoDaddy, Oracle Cloud, GCP, and AWS. None of them worked, but I gained a wealth of knowledge along the way.
Hosting isn’t as simple as clicking a few buttons. Much respect to infrastructure engineers.
Eventually, I decided to split the app into two parts:
A webpage for user registration, subscriptions, and downloads.
A desktop application for the actual image search.
Lesson 2: Packaging a desktop app is its own monster
This separation seemed like a brilliant solution — until I spent countless nights bundling the desktop app into a .dmg file.
First I needed to separate the functionalities between the website and the desktop app, ensuring each worked on its own while maintaining smooth communication with one another. At first, this felt manageable — almost easy.
Then came the real challenge: bundling.
That’s when the monster truly emerged, revealing one issue after another:
Path Inconsistencies: What worked in development didn’t translate to the standalone app.
App-Website Communication: Maintaining a local database carrying user information proved easier than relying on APIs.
Bundling Challenges: Port conflicts, system permission errors, Apple developer certificates and code signing processes became my nightly battles.
Even AI, my helpful assistant, occasionally threw curveballs with hallucinated solutions that led me astray. Imagine a mischievous 3-year-old with 100 years of wisdom guiding your every move.
This process brought a rollercoaster of emotions: surprise, frustration, joy, despair, and everything in between.
The Final Product
Despite the hurdles, I finally have a functional app that runs smoothly on macOS.
Check out Find In Folder here →
If you’d like to try it out, I’m excited to offer a 100% discount with the coupon code SECRETWAIVE. Your feedback would mean the world — feel free to share your ideas, and together we can make the experience even better.
Closing Thoughts
Building an app is only 10% of the work. The other 90% involves everything outside of coding.
We often focus on writing code to create a seamless user experience, but that’s only the starting point. When it comes to launching, you quickly realize the need to address user needs from every angle: hosting, auth, monetization, packaging, communication.
My first vibe coding app was a rollercoaster of frustration, learning, and growth. The harsh reality? Coding is merely the beginning. Bringing a product to life requires tackling the intricacies of user experience, ensuring system reliability, and committing to ongoing improvements.
If you’re thinking about launching your own app — the 10/90 rule is the one thing to internalize before you start, not after you’ve hit every wall.
What I’d Build Differently Today (2026 Update)
I built this with Cursor in early 2025. Three things would change with Claude Code:
1. CLAUDE.md replaces the per-session re-explanation. Every Cursor session, I re-explained the app structure, the subscription model, the ML dependencies. With Claude Code, that context lives in one file and loads every session automatically. The onboarding guide covers how to structure that file so Claude knows your project from the first message.
2. Oracle Cloud from the first session. I wasted weeks on platforms that couldn’t handle ML before landing there. The OpenClaw setup guide documents the Oracle Cloud configuration that ended up working — go there first and skip the 5-platform cycle.
3. The architecture split is still right. Compute on the client, lightweight web layer for auth and distribution — that decision holds regardless of tool. Start with the simplest infrastructure that works, add complexity only when the simple version breaks under real load.
What hasn’t changed: every project after this one got faster because the first one was hard. The second app launched much smoother. By the third, the patterns were obvious. The 10/90 rule doesn’t go away — you just get better at planning for it.
I help non-technical people ship real products with AI. If you want to go from chatting with AI to building systems with it, the Practical AI Builder program is where that happens.
Why Upgrade · Practical AI Builder Program · Templates · Builder Showcase