Vibe Coding: What Key Steps Are Missing Between Demo and Launch?

Since Vibe Coding (programming by feel, using natural language instructions to have AI generate products) became popular, social media feeds have been flooded daily with sharing videos like "I built an App" or "I whipped up a website." Describe your requirements to AI, tweak some details, and the interface runs smoothly with core workflows functioning—it looks just like a complete product.

Vibe Coding was originally coined by Andrej Karpathy (OpenAI co-founder and former Tesla AI Director) in early 2025. He described an entirely new programming paradigm: developers no longer write code line by line, but instead describe desired functionality in natural language to AI (using tools like Claude, GPT-4, Cursor, etc.), and AI handles the concrete implementation. The developer's role shifts from "the person who writes code" to "the person who directs AI"—more like a product manager or creative director. This model's popularity stems from the rapid advancement of large language models' code generation capabilities and the maturation of AI coding tools like Cursor, Bolt, and Replit Agent.

But the reality is: a large portion of these creations are still stuck at the demo stage and don't actually meet the conditions for a real launch. Many people have been fooled by this illusion of "it works"—eager to share the moment it runs on their own phone, only to realize there's still a long road ahead when someone asks "where can I use it?"

This article uses a "budgeting App" as an example to systematically outline what exactly stands between an AI-generated working demo and a formal product ready for real users.

The Fundamental Difference Between a Demo and a Product

The standard for a "working demo" is typically quite low: you can input an expense, see how much you've spent, edit entries, delete them, and maybe even do some data analysis. Install it on your own phone, and it counts as "working."

But "I can use it myself" and "everyone can use it" are two completely different things. The former only requires functionality to work along the happy path; the latter demands consideration of deployment, data, accounts, exception handling, maintenance, and an entire engineering and product system.

Happy Path is a classic concept in software testing, referring to the flow where users complete operations exactly as the designer intended, under perfectly normal conditions. Its counterparts are Sad Path (exception paths) and Edge Cases. In professional software development, engineers typically spend 60%-80% of their time handling non-happy-path scenarios—network interruptions, illegal user input, concurrency conflicts, insufficient permissions, etc. This is why a seemingly simple feature can balloon 5-10x in workload from demo to production-grade code.

The core insight is: In an era where everyone can Vibe Code a working product, what truly sets people apart is having good ideas, actually launching and monetizing, and the ability to maintain it over time.

Deployment: Making Your Product Accessible to Others

To let others use what you've built on your own computer, you first need an accessible entry point.

For web products, you need to purchase a domain (and in China, possibly go through ICP registration), then package and deploy the project to that domain. For apps, you face two different launch processes for Android and iOS—iOS additionally requires purchasing a developer account, preparing product preview screenshots, filling out various forms, and completing the review process.

Apple's App Store review is one of the industry's most stringent app distribution gatekeepers. Developers must first purchase the annual $99 Apple Developer Program membership, then package the app as an IPA file through Xcode and upload it to the App Store Connect platform. The review team conducts both manual and automated reviews across multiple dimensions including functional completeness, UI guidelines compliance, privacy policies, and content compliance. The cycle typically takes 24-48 hours, but modifications and resubmissions after rejection can take weeks. Common rejection reasons include: app crashes, missing privacy descriptions, overly simplistic functionality (deemed a demo rather than a complete product), and failure to use Apple's In-App Purchase system for digital goods payments.

This step seems simple, but it's a threshold many demos never cross. Running locally doesn't mean it will serve users stably after packaging and deployment.

Data Storage and User Account Systems

When users can finally open your budgeting App and log an expense, new problems immediately follow:

• Users don't want data to disappear on refresh;
• They certainly don't want others to see their bills when opening the product.

This means the product must solve two things: data needs persistent storage, and the product needs to know who each transaction belongs to.

Data persistence refers to saving data generated during program execution to long-term storage media, so it survives app closure or device restart. For independent developers, mainstream backend solutions currently include: Firebase (a BaaS service from Google integrating real-time databases, authentication, cloud functions, etc.), Supabase (an open-source Firebase alternative built on PostgreSQL), and Serverless solutions like Cloudflare Workers + D1. These services dramatically lower the barrier to backend development—developers don't need to manage servers themselves—but they still need to understand core concepts like data model design, API security, and data backup strategies.

Modern app account systems typically implement third-party login via the OAuth 2.0 protocol (such as WeChat Login, Apple ID Login, Google Login), or use phone number/email + verification code. The core of an account system isn't just "letting users log in"—it's establishing data ownership relationships. Every data record needs to be associated with a user ID, and queries should only return data owned by the current user. This involves Row Level Security at the database level, authentication middleware at the API level, and token issuance and refresh mechanisms. For Vibe Coding-generated projects, this logic is often where security vulnerabilities are most likely to appear.

User account systems and data ownership are the dividing line between a "toy" and a "product." When users return to the product, they should only be able to see, modify, and delete their own data.

Backend Services and Complex Feature Support

Beyond storage and accounts, many valuable features depend on continuously running backend services. For example:

• Automatically generating daily spending summaries;
• Sending scheduled reminders;
• Using AI to analyze users' spending habits and provide suggestions.

These features might work perfectly during local demos, but after launch they require independently deployed, continuously running backend support. As products grow more complex, you'll also need to consider user permissions, data security, data backups, and how to recover when things go wrong—all operational-level concerns.

Payment Flow: From Display to Actually Working

If you decide to monetize your product, you need to implement complete purchase and unlock logic.

The challenge here isn't just integrating a payment provider—it also includes a series of product decisions: When should the paywall appear? Which features are free and which are paid? At this stage, AI-generated products can typically only "show that payment is needed here" or help design the payment page, but actually getting the complete payment flow working end-to-end is what matters.

Integrating a payment system is far more complex than "calling an API." On iOS, digital content and services must use Apple's In-App Purchase, with Apple taking a 15%-30% commission. Developers need to handle purchase receipt verification, subscription status syncing, refund callbacks, family sharing, and tax compliance across different countries/regions. On domestic Web/Android platforms, you'll need to integrate WeChat Pay or Alipay, handling payment callback notification idempotency (preventing duplicate charges or duplicate deliveries), order timeout closures, and reconciliation. Bugs in payment workflows directly involve financial security, making this the least error-tolerant part of any product.

Special note: the cost of errors here is extremely high—real money is involved, and there's no room for carelessness.

Exception Handling and User Onboarding

This is where the gap between demos and real products is largest. Demos typically showcase only the ideal flow (happy path), while in reality users will operate in all sorts of unexpected ways.

Onboarding

When users first open the app, they might not set a monthly budget, causing the system to fail to alert them when overspending—making them miss the product's most valuable feature. Therefore, you need to guide users through entering necessary information on first launch to ensure they can experience the full functionality afterward.

Onboarding design is backed by deep product psychology principles. Research shows that users form their judgment of a product's value within the first 3-5 minutes of use. If they fail to experience an "Aha Moment" within this window, churn rates spike dramatically. Good onboarding design follows the principle of progressive disclosure—rather than requiring users to complete all setup upfront, it guides them to complete necessary configurations just as they're about to use a relevant feature. For example, a budgeting App could first let users log their first expense (zero-friction experience of the core feature), then guide budget setup at an appropriate moment.

Edge Cases

Users might enter incorrect content, accidentally deny permissions, or exit mid-way through a long flow... Each of these requires designing error states for every feature flow and guiding users back to the correct path.

State Design

For a smoother experience, you also need to add loading states, empty states (what to show when a page has no data, and how to guide users to get started), and other details. These aren't flashy and won't appear in demo videos, but they're essential for the user experience of a launched product.

Post-Launch Maintenance and User Feedback

Building a product for yourself versus handing it to the public are two completely different things. Everyone has different devices and different usage habits—a product you consider flawless might be riddled with bugs and terrible experiences in someone else's hands.

Without users, you get no feedback. Without feedback, you can't determine what to maintain or what features to add. Therefore, a feedback channel that's easy to discover, not cumbersome to use, and ideally supports two-way communication is crucial. Only by actually receiving user feedback can you validate whether the product is usable and whether anyone is truly willing to pay.

In Lean Startup methodology, the "Build-Measure-Learn" loop is the core framework for product iteration. For independent developers, common feedback collection methods include: in-app feedback portals (like shake-to-report), user communities (WeChat groups/Discord), app store review monitoring, and analytics event tracking to understand user behavior. Event tracking is particularly important—users won't proactively tell you where they got confused or dropped off, but behavioral data will. Tools like Mixpanel, PostHog, or China's Umeng can help developers track key funnel conversion rates, enabling data-driven product decisions.

What Truly Sets You Apart Is Judgment

AI can actually help you handle most of the stages mentioned above—you can even directly ask AI "what's missing before my product can launch."

But what truly requires human judgment is:

• What must be done now? What can wait?
• Is the solution AI provided correct?
• Is this solution right for my specific product?

When AI has leveled the barrier to "generating a working product," product thinking, prioritization skills, and the ability to sustain operations become the developer's true moat. Vibe Coding has lowered the cost of "building it," yet paradoxically amplified the value of "getting it right, making it good, and making it last."