Vibe Coding in Practice: A Complete Guide to Building a Commercial Booking Mini Program with AI

From Demo to Delivery: How AI Coding Handles Real Commercial Projects

Most people who learn AI-assisted coding stop at the "build a demo" stage. But real commercial projects require a complete loop: page replication, backend APIs, WeChat Pay integration, admin dashboards, and production deployment. This tutorial uses a real booking mini program as a case study, walking through the entire process from client requirements gathering to final acceptance and launch. It's a highly practical Vibe Coding guide grounded in real-world delivery.

Vibe Coding — a term coined by AI luminary Andrej Karpathy in early 2025 — describes a development paradigm where developers no longer write code line by line. Instead, they describe requirements in natural language and let AI coding assistants (like Cursor, Windsurf, or GitHub Copilot) generate the code, with developers focusing primarily on review and iteration. The concept spread quickly and represents a paradigm shift in AI-assisted development: from "code completion" to "requirements-driven development." What this article demonstrates is a complete, real-world application of Vibe Coding in a commercial delivery context.

The entire project is broken into five major phases: theory, requirements breakdown and page replication, backend APIs and WeChat Pay, integration debugging, and admin panel plus deployment. The core objective was to replicate the key features of a reference mini program provided by the client — matching its general visual style while integrating real WeChat payment capabilities.

Two Guiding Methodologies That Run Throughout

Before diving in, the author emphasizes two golden rules that form the soul of the entire tutorial:

• Replicate first, then refine: Break down the page structure and interactions clearly upfront. For layouts that are hard to describe in words, use screenshots with annotations so the AI knows exactly what to change.
• Provide complete error feedback: When something breaks, give the AI the full error message and the exact steps that led to it. After each round of changes, compile, run, and test. Work from static UI to interactive logic — phased validation is the only way to isolate which step caused the problem.

This "screenshots + phased validation" approach is the key to guiding AI coding with natural language as a non-expert. It lowers the bar for traditional programming skills, but it doesn't lower the bar for engineering thinking — particularly the ability to decompose problems and validate quality.

Requirements Breakdown and Page Replication

The project began with a reference mini program provided by the client. The author first mapped out the full page structure: the home screen featured a top carousel banner, eight functional entry points, and product listing cards; the detail page included an image carousel, booking instructions, and a "consult now" button; the booking page required date, time, and group size selection plus payment integration; the "My" page displayed order status; and merchant information was managed through the admin panel.

Driving AI Development with Natural Language and Screenshots

After loading the entire project folder into the AI coding tool, the author didn't spend time crafting elaborate prompts. Instead, they described the requirements directly in plain language: telling the AI this was a booking mini program, that a ready-made frontend template was already included, that subsequent pages should follow the same template, and that the bottom Tab Bar navigation needed to be configured. The Tab Bar is a native bottom navigation component provided by the WeChat Mini Program framework — configured via page paths, icons, and labels in app.json — and is a standard UI element in virtually every mini program.

The first round focused exclusively on static pages, with no API calls or data logic. This is a smart strategy: decoupling UI replication from business logic means you validate the visual layer first, then layer in functionality incrementally — significantly reducing the complexity of debugging in each round. The author then took screenshots of the reference mini program's home, booking, and "My" pages and uploaded them for the AI to read and use as the basis for code modifications. The first generation took about 20 minutes.

Review was done through side-by-side comparison: running the development build on one side and the reference mini program on the other, checking carousel padding ratios, gradient transitions, icon arrangements for the eight entry points, and product card structure. Issues like slightly distorted images or remote images not loading were logged temporarily, to be addressed once the backend assets were connected.

The "static-first" strategy has particular significance in AI-assisted development. Experienced engineers can handle UI and business logic simultaneously, but the more complex the context and the more system layers involved in a single AI conversation, the higher the probability of generating incorrect code. Breaking the task into three phases — static UI, then interactive logic, then API integration — is fundamentally about controlling the complexity handed to the AI in each pass, making it easier to generate correct code. This aligns with the software engineering principle of Separation of Concerns, but in the context of AI coding, it becomes not just an architectural principle but a human-AI collaboration workflow strategy.

Filling in Missing Interaction Logic

Once the static styling passed review, the author started testing buttons and navigation — and found that clicking the functional entry points did nothing. This confirmed an important insight: the AI only implements what you clearly describe; missing interactions need to be explicitly added. Current large language models reason and generate based on the context you provide; they can't proactively "fill in" business scenarios you haven't mentioned. The completeness of your requirements description directly determines the quality of the generated code.

The second round therefore focused on interactions — capturing before-and-after screenshots of the category page, product detail page, consultation popup, and booking selection flow, then describing "what should happen when clicked" in full, including the logic for disabling expired dates and fully-booked time slots on the booking page.

Backend APIs and WeChat Pay Integration

Once the frontend pages were complete, it was time for product data, bookings, and user information to actually read from and write to the database. This reflects the frontend-backend separation architecture common in modern development: the frontend (mini program) handles UI and user interaction, while the backend provides data services via RESTful APIs over HTTP. This architecture allows the frontend and backend to be developed, deployed, and scaled independently, and makes it easy to reuse the same backend for multiple clients — for example, if an H5 version or admin panel is added later, the backend APIs don't need to be rewritten.

To keep costs down, the author reused an existing backend service from a previous project — two projects sharing one server and one database.

Following Existing Code Conventions

This is a notably professional detail: the author explicitly instructed the AI to organize new APIs following the existing project's code conventions, maintaining the layered structure of Controller, Service, and DAO/Repository — not introducing a different pattern. This three-tier architecture is the standard code organization approach in enterprise projects: the controller layer handles incoming HTTP requests and returns responses, the service layer encapsulates core business logic and process orchestration, and the data access layer manages direct interaction with the database. This layered design enforces separation of concerns, making code easier to maintain, test, and extend. For the AI, clear architectural constraints also help generate code that is stylistically consistent and structurally clear, rather than arbitrarily assembled.

New modules added included authorization and login, product list/detail, and booking APIs, with corresponding database tables and fields generated in sync.

Since both projects shared the same database, the author required that each business record include a project identifier for data isolation, preventing cross-contamination with the original project's data — a reflection of real-world commercial data security requirements. In actual multi-tenant or multi-project architectures, data isolation is a baseline requirement. Common approaches range from field-based identification (as used here) to separate schemas or separate databases, with increasing complexity and security levels.

WeChat Pay Integration and Debugging

Integrating WeChat Pay in a mini program is a complex, multi-party process. The developer must register a merchant account on the WeChat Pay platform and obtain API keys and certificates; the backend implements a unified order creation API (which calls WeChat Pay's API to generate a pre-payment order); the frontend uses wx.requestPayment to invoke the payment popup; and after payment, WeChat's servers send an asynchronous callback to the backend to confirm the order status. The entire flow involves signature verification, encrypted communication, and state synchronization — with extremely high security requirements, making it one of the most error-prone parts of any mini program project.

During initial testing, WeChat login kept loading indefinitely on a standard debug page, but succeeded after switching to WeChat DevTools. WeChat DevTools is the official integrated development environment provided by WeChat, with a built-in mini program runtime simulator that can authentically simulate API calls that require the WeChat environment — like login and payment. It's an essential tool for mini program development and debugging. Bookings could be created, but the app returned a "payment interface not configured" message, indicating that the basic API was working but payment hadn't been integrated yet. The author then asked the AI to add the WeChat Pay API, with a specific emphasis: merchant IDs and secret keys should be stored only in configuration files, never written directly into business code — protecting credentials while making them easy to swap. This is a fundamental secure coding principle: sensitive credentials should be managed via environment variables or dedicated configuration files to prevent hardcoding and leakage, and this is especially important when using AI coding tools, where code snippets may be uploaded to the cloud for processing.

When using AI coding tools to help implement payment features, there's an easily overlooked risk: AI-generated code may write merchant keys, API certificates, and other sensitive credentials directly into source code files. If the AI coding tool you're using (such as Cursor or GitHub Copilot) uploads code snippets to the cloud for analysis, those credentials could be exposed during transmission and storage. Beyond keeping sensitive parameters in config files as mentioned above, you should also add config files to .gitignore to prevent them from being committed to a code repository, and use environment variables or secrets management services (such as AWS Secrets Manager or HashiCorp Vault) to inject sensitive configuration in CI/CD pipelines. These security practices are more important in the age of AI coding than ever before.

Real Debugging: Don't Skip a Single 500

This section is the most valuable part of the entire tutorial, because it shows the back-and-forth debugging process of real development without idealization. HTTP status code 500 (Internal Server Error) indicates an unexpected error occurred on the server side. It's the most common and frustrating error code in backend development, because it only tells you "something went wrong" — the actual cause requires correlating server logs with code logic.

When the author walked through the login flow with a new user, the API returned a 500 error. His approach is worth learning from: first delete old test users from the database and clear the developer tool's local cache to eliminate interference from historical data, then pass the API endpoint, response status code, and exact steps to the AI for diagnosis. It doesn't matter if you don't know the cause yourself — let the AI trace through the backend logs and code. This reflects the core Vibe Coding mindset: developers don't need to master every implementation detail, but must have a clear debugging approach — isolate variables, reproduce the problem, and provide complete context.

Subsequent issues arose one by one: a "service temporarily unavailable" error on booking submission, missing category images, and the "My" page not displaying the user's avatar or nickname. The author consistently followed one principle: describe each issue separately, never bundle multiple problems into a single message, and reproduce the steps each time so the AI sees the complete flow. This corresponds to an important technique in AI interaction — large language models perform significantly better on single, well-defined tasks than on vague, multi-problem descriptions. Submitting issues one at a time substantially improves the AI's accuracy in locating and resolving problems. After multiple cycles of "fix → clear cache → re-login → verify," login, images, and booking orders were restored one by one.

Admin Panel and Production Deployment

With the mini program's core features complete, the author built out the admin management system: merchants can maintain product pricing and store information, and view user orders and booking records. The admin dashboard displays summary statistics for users, products, orders, and bookings, with live data linkage to the mini program. The admin system is typically a separate web application that calls the same backend APIs as the mini program to read and write data — achieving "one dataset, managed across multiple interfaces."

Frontend-Backend Separation Deployment Flow

Deployment followed a frontend-backend separation approach: the backend was packaged into an artifact and uploaded to the server, where a new service was created, ports were configured, and the service was started. The API documentation was then accessed via "server IP + port + endpoint path" to verify external availability. API documentation (typically auto-generated from Swagger/OpenAPI specs) is an important tool for frontend-backend collaboration — it lists each endpoint's request method, parameter format, and response structure, and is the first means of verifying that the backend service is running correctly.

The author candidly noted that the domain had not yet completed ICP filing, so the demo used the server IP directly, with a recommendation to switch to a properly filed and SSL-certified domain for production launch. In mainland China, all websites and applications serving traffic via a domain name must complete ICP registration (a mandatory requirement from the Ministry of Industry and Information Technology). WeChat Mini Programs have even stricter restrictions on backend APIs: officially published mini programs can only make requests to ICP-registered domains, and those domains must use HTTPS (i.e., SSL certificates for encrypted communication). Unregistered domains cannot be used in production mini programs — which is the root cause of the deployment issues the author encountered. The ICP filing process typically takes 10–20 business days, so developers should start the process in parallel at the beginning of a project to avoid being blocked at launch.

Switching to the production API introduced another snag: after changing to the domain name, requests returned no data. Investigation revealed the ICP filing issue, and reverting to the IP address resolved it. This detail serves as another reminder that differences between deployment environments are often the source of new problems. Configuration differences between development, staging, and production environments (such as domain names, ports, certificates, and network policies) are the most common cause of "works locally, breaks in production" — which is why DevOps emphasizes "environment consistency" and "infrastructure as code."

Finally, the author entered the version number in WeChat DevTools and uploaded the code, with the option to submit for review or set it as an experience version for the client to validate first. The admin website was similarly packaged, uploaded, extracted, and bound to the site root directory before going live. Mini program releases require official WeChat review (typically 1–7 business days) before becoming available to all users. The experience version bypasses review and lets designated users try the app early via QR code scan — ideal for client acceptance scenarios. At this point, the mini program, backend APIs, and admin panel were all deployed and fully connected.

Summary: A Reusable AI Coding Methodology

The value of this project lies not in producing a booking mini program, but in validating an AI coding methodology transferable to any real-world project:

1. Replicate first, then refine — break complex requirements into clear pages and interactions;
2. Use screenshots to describe problems — compensate for the limitations of natural language;
3. Provide complete error context to the AI — including the API endpoint, status code, and steps taken;
4. Validate in phases — static UI before interactions, basic APIs before payment;
5. Follow existing conventions and enforce data isolation — guide the AI to produce commercially-standard code.

For developers looking to take on real commercial projects with AI coding tools, this workflow of "screenshots + phased validation + real debugging" is more practical than any elaborate prompt template. It reveals a core truth: AI coding tools lower the barrier to writing code, but they don't lower the barrier to engineering delivery — requirements decomposition, quality validation, deployment, and security awareness remain the critical skills that transform a demo into a shippable commercial product.

From a project management perspective, this methodology also implies an important shift in cost structure. In traditional outsourced projects, development labor is the dominant cost. As AI coding drastically compresses coding time, the cost center shifts toward requirements communication, testing and acceptance, and deployment operations. This means the core competitive advantage of AI-assisted developers is no longer "speed of writing code" but "the ability to understand requirements and deliver reliable products." At the same time, clients will expect shorter delivery timelines — meeting higher quality standards in less time requires developers to build standardized project templates, reusable backend services (like the shared server strategy in this article), and efficient acceptance workflows.