From Prototype to Production: What to Add Before Customers Use Your App

Plants.work · · upskilling
From Prototype to Production: What to Add Before Customers Use Your App

Six things to add when your vibe-coded app gets real customers: separate environments, critical-path tests, error alerts, backups and more.

The prototype you vibe coded last month is starting to get real users. Friends recommend it, and customers ask, "Can I pay through the app?" It is an exciting moment, and also the most dangerous one, because something built to "try out" is now being used like a "real system". This article covers what to add before customers rely on your app, building on Build an app with AI in one day, which takes you as far as an MVP.

How prototype and production differ

A prototype answers "does this idea work?" Production has to answer "if something breaks, who knows, when do they know, and can we recover?" The difference is not features. It is reliability, security and the ability to maintain the system.

6 things to add before going to production

1. Separate environments

Do not try new features on the database customers are using. Have at least two setups: a test environment (development or staging) and the real one (production), each with its own keys and database. Services such as Supabase offer Branching, which its Features page describes as testing schema changes in an isolated environment before they reach production.

2. Version control and review

Connect the project to GitHub so every change has a history and can be rolled back. Even better if someone reviews changes before they reach production, especially anything touching permissions, data or money.

3. Test the critical paths

You do not need to test everything, but you must test the paths that would hurt the business if they broke, such as sign-up, login, booking and payment. Write them as a repeatable checklist to run before every release, or ask the AI to write automated tests for these paths.

4. Monitoring and alerts

With a prototype, you find out it broke when a friend messages you. In production you should know before customers do. Set up error and log collection on the backend, with alerts for unusual errors. A simple start: ask the AI to log errors in key functions such as booking and payment, and email you when they repeat several times in a short period.

5. Backups and a recovery plan

Supabase's Features page lists daily backups and point-in-time recovery options. Whatever service you use, check that backups are on and, more importantly, that you have actually tried a restore at least once.

6. Non-code essentials

Example: a yoga studio in Phuket

A studio owner built a class booking site with vibe coding and used it with a small group of members for months. Before opening online package sales, she replans: separate test and production databases, connect GitHub, hire a freelance developer to review payments and permissions, write a 5-path test checklist that must pass before every release, and turn on email error alerts. In the first week the system flags double bookings in the same class. She knows and fixes it before members run into the problem at the studio.

A prototype proves the idea works. Production proves customers can trust it.

Things to watch out for

What to do next

  1. List your app's critical paths, no more than 5
  2. Separate test and production environments, and connect GitHub
  3. Turn on backups, try a restore, and set up error alerts
  4. Run the security checklist before opening to customers

Taking a project from prototype to a system people rely on is a skill employers look for. To see what roles in this area ask for, search the Plants.work jobs page.