How to Take a Vibe-Coded App to Production: A Founder's Playbook

Getting the app online is only part of taking it to production. Before launch, you need to check authentication, permissions, user data, secrets, and how the app handles failed requests or payments. You also need backups, error logging, monitoring, and a safe way to release updates.

Do not start by rebuilding the app because it was made with Lovable, Bolt, Replit, Cursor, or another coding tool. Review what you already have first. Fix the high-risk problems, test the main user flows, and make sure you control the source code, domain, database, hosting, payment account, and other services the product depends on. Some apps only need a few changes before launch. Others need more work on security, testing, infrastructure, or code that worked for a prototype but isn't ready for production.

This guide explains how to take a vibe-coded app to production, from reviewing the code and securing your accounts to setting up hosting, deployments, backups, monitoring, compliance, and the work that continues after launch.

What "Production-Ready" Actually Means for a Vibe-Coded App

A working app tells you that the main features are there. It doesn't tell you what happens when a request fails, two users update the same data, a payment is sent twice, or a new release introduces a bug.

Before taking a vibe-coded app to production, we look beyond the features that already work. We check how the app protects user data, what happens when something fails, and whether the team has enough information to find a problem after launch.

We also look at the setup around the code. Backups, monitoring, deployments, database access, and control of the services the app depends on all matter once real users are involved.

Live Doesn’t Mean Production-Ready

Publishing an app with Lovable, Bolt, Replit, or another platform shows that it runs. It does not show how the app will behave when something goes wrong after launch.

During development, you probably tested the main flow. A user signs up, logs in, uses the feature, and gets the expected result. We go further than that before taking an app to production. We test what happens when a request fails halfway through, the same action is submitted twice, or a service the app depends on stops responding.

If something fails, we check whether the app leaves incomplete data behind and whether the error is logged clearly enough to find the cause. These problems are easy to miss when testing only the normal user journey.

We check recovery as well. A backup needs to be restorable, not simply available. If a release breaks login, payments, or another important feature, the team should have a clear way to return to the last working version.

The feature may already work. Before launch, our job is to check whether the application is ready for the problems that come with running it for real users.

Who’s Really Responsible for Security?

Using Lovable, Supabase, Vercel, or another managed platform doesn't make the app secure by default. The provider protects its platform, but your team is still responsible for how the app lets users access data and sensitive features.

We start by checking database access. A user might log in correctly but still be able to see someone else's data. This happens when the app verifies who the user is but doesn't properly check which records that user can access.

Credentials also need to be checked. Private API keys, database credentials, and service tokens should not appear in frontend code or a public repository. If they are exposed, we move them to the server or a secure place provided by the hosting platform.

For payments, we review the live keys, checkout flow, and webhooks. We also check sensitive backend actions to make sure a user cannot perform something just because they know which request to send.

A feature working correctly doesn't mean it is secure. Before launch, we check how the app protects customer data, credentials, payments, and other actions that only the right user should be able to perform.

Is Your App Ready? Take the 2-Minute Test

You do not need a long audit to find the first signs that a vibe-coded app is not ready for production. These are some of the checks we make early in a production review.

• Do you own the important accounts? You should have access to the source code, domain, hosting, database, payment account, and other services the app depends on.
• Can one user see another user's data? Test the app with two separate accounts. Change record IDs and try actions that should belong to the other user. The request should be blocked.
• Are any secrets exposed? Check the frontend code and repository for private API keys, database credentials, tokens, and other secrets. If a real credential has already been exposed, removing it from the code is not enough. It should be replaced or revoked.
• Are payments ready for real transactions? Check the live payment keys, checkout flow, and webhooks. Sending the same webhook more than once should not create the same order, payment record, or account update twice.
• Can you restore your data? Seeing successful backups in a dashboard is not the same as knowing they work. Restore one in a safe environment and confirm that the data is usable.
• Will you know when the app breaks? Important errors and downtime should reach someone on the team. You should not have to wait for a customer to report that login or checkout has stopped working.
• Can you undo a bad release? Before pushing an update, know how you will return to the last working version if the new release causes a problem.

Finding a problem here does not mean the app needs to be rebuilt. It gives us a place to start. At CodingCrafts, we use checks like these to find the immediate risks first, then look deeper into the code where the application needs more work.

Step 1: Take Ownership of Your Code, Accounts and Domain

Before we work on the code, we check who actually controls the app. A founder might own the product but still have the repository under a freelancer's account, the domain under a personal email, or the production database inside an account they cannot fully access.

Start with the source code. Keep it in a Git repository managed by your company, not as the only copy inside a coding tool or someone else's account. If you use a GitHub organization, give at least two trusted people the owner role so access does not depend on one person.

Then go through the services the app relies on. Check the domain and DNS, hosting, database, payment provider, email service, and any other account the application needs to run. The company should control the billing and administrative access for these services.

We also check production credentials during this work. Database passwords, payment keys, and private API keys should not be stored in frontend code, committed `.env` files, or shared through documents and chat messages. Move them into the secret management provided by your hosting or infrastructure setup.

If we find a real production credential that has already been exposed, moving it is not enough. We replace or revoke it and update the application to use the new credential. With these accounts under company control, we can work on the application without depending on someone else's access.

Getting Your Code Out of Lovable, Bolt, Replit, or Cursor

Each coding tool gives you a different way to work with the project. We need the latest code in a company-owned repository that another developer can clone, review, and continue working on.

Having the code in GitHub does not mean everything has been transferred. The database could still belong to a personal Supabase account, or payments could still run through a Stripe account the company doesn't own.

We trace these connections as part of the handoff. To test the app, change production settings, deploy a release, or recover from a problem, the developer needs access to the services behind the code as well. After that, we can move into the application itself and see what needs to change before launch.

Step 2: Run the Production Readiness Checklist

Once we have access to the code and accounts, we check what could put the launch at risk. A security gap, failed payment, missing backup, or broken recovery process needs attention before duplicated code or naming issues.

We do not try to fix everything at once. We separate what needs to be fixed before launch from the work the app will need as more users arrive. Anything that doesn't affect security, key user flows, or recovery can usually wait.

Start with the issues that need to be resolved before real users depend on the app.

Fix These Before Launch

Fix some problems before anyone starts using the app. We focus first on anything that could expose customer data, affect payments, take the app down, or make recovery difficult.

Test access with two user accounts. Create two users and try to access one account's data while signed in as the other. Check the requests sent to the server and what you see on the screen. The server should block the request if that user does not have permission to access the record.

Check for exposed secrets. Look through the frontend code, repository, and Git history for private API keys, database credentials, and service tokens. If a real credential has already been exposed, we rotate or revoke it. Removing it from the latest file is not enough.

Validate input on the server. A form might already check what a user enters, but those browser checks can be bypassed. We check the data again on the server before the application uses it. The rules depend on what the field should accept, such as a specific format, length, or value.

Test payments from start to finish. We check the live payment settings, checkout flow, and incoming webhooks. If the payment provider sends the same webhook twice, the app should not create the same order or update twice. We also test failed payments and refunds if the product supports them.

Restore a backup. Do not stop at checking whether backups are running. Restore one in a safe environment and make sure the data is there. The team should also know where to find the recovery steps if production data needs to be restored.

Set up alerts for serious problems. If the app goes down or starts returning important errors, someone on the team needs to know. We set up alerts so the first sign of a problem doesn't come from a customer.

Test the rollback process. Keep the last working release available and try returning to it before launch. If a future deployment breaks login, payments, or another important feature, the team already knows how to restore the working version.

Put limits around paid AI features. If the app uses a paid AI service, check what spending controls and usage alerts the provider offers. We also look at how often expensive endpoints can be called. A bug or repeated requests should not be able to create a large bill without the team noticing.

Get These Right Before Your Next 100 Users

The app needs a little more structure as usage grows. More users mean more data, more requests, and more releases going into production. We put the following pieces in place before those changes start making releases harder to manage.

Set up a separate staging environment. We use staging to test a release before the same code reaches production. It should have its own credentials and configuration, so a test does not accidentally write to the production database or call a live service. We also avoid copying real customer data into staging unless we clearly need it and protect it properly.

Track database changes with migrations. Database changes should move with the code. If we add a table, rename a column, or create an index, we record that change as a migration. We run the same migration in staging first, then in production. This keeps the database structure consistent and removes the need to remember which changes were made manually.

Automate the main user flows. We start with the actions that would cause the biggest problem if they stopped working, such as sign-up, login, payments, and account deletion. These tests run when the code changes or before a release. If an update breaks one of those flows, we want to find it before the new version reaches customers.

Add rate limits to the right endpoints. We do not use one limit across the whole application. Login and password reset need protection against repeated attempts, while AI and other expensive endpoints need limits based on how the product is normally used. We test what happens when the limit is reached as well, so legitimate users do not end up with a broken flow.

Load tests the parts that do the most work. We start with API requests and features that hit the database heavily or are likely to receive the most traffic. Then we increase concurrent requests and watch response time, error rate, database connections, CPU, and memory. If performance starts dropping, those numbers help us find whether the problem is in a query, application code, database connection limit, or another service before more users reach it.

What Can Wait Until Later

Not every issue we find needs to delay the launch. Duplicated code, inconsistent naming, or code that could be cleaner can stay for now if it is not causing bugs, creating a security risk, or making an important feature difficult to change.

Some documentation can wait too. Before launch, the team should already know how to deploy the app, restore a backup, roll back a release, and access the services the application depends on. Detailed documentation for every function or smaller part of the codebase can be added later.

We also do not refactor working code just because there is a cleaner way to write it. Every change introduces something else that needs to be checked. If the code works, is safe, and is not getting in the way of development, we leave it until there is a reason to change it.

Before launch, we spend engineering time on problems that could expose customer data, affect payments, break an important feature, or leave the team unable to recover the app. Lower-priority cleanup can come after that.

Step 3: Decide Where Your App Will Run

A production app does not need to leave Lovable, Bolt, Replit, or another platform just because it is going live. If the current hosting supports what the product needs, moving it adds work without solving a problem.

We check how the app uses compute, storage, databases, background jobs, and other services. We also look at expected traffic, security requirements, and how much control the team needs over the infrastructure. That tells us whether the current setup is enough or whether part of the application needs to move.

Can You Stay on Your Builder’s Hosting?

For some apps, builder hosting is enough for production. If the application runs reliably there and the platform gives the team the controls it needs, we do not move it just to have a more complex infrastructure setup.

Before keeping the app there, we look at how the platform stores secrets, exposes application logs, and responds when usage grows. We also check its limits for compute, bandwidth, storage, and other resources the application depends on. These limits matter more once real traffic starts reaching the product.

We also look at what happens when something goes wrong. The team needs a way to find production errors, monitor the app, restore important data, and recover from a bad release. A managed platform takes care of some infrastructure work, but it does not remove the need for these checks.

If the builder supports the application's current traffic and technical requirements, staying there is a reasonable production setup. We recommend moving when the existing platform starts getting in the way of something the product actually needs.

When It’s Time to Move to Your Own Cloud

We look at moving when the current hosting starts limiting something the application actually needs. That could be a background worker that needs to keep running, scheduled jobs, private networking, a specific hosting region, or more control over how the application scales.

Security or compliance requirements can also change the setup. A company might need tighter network controls, specific data locations, or infrastructure that fits into an existing cloud environment. In that case, we check whether the builder still gives the team enough control before deciding what needs to move.

Cost matters as usage grows too. We look at how compute, storage, bandwidth, database usage, and other services affect the bill at the traffic the product expects. A platform that works well for an early version might become expensive once usage changes.

Moving does not mean the team has to manage servers itself. A managed hosting platform may provide the extra control the application needs without adding much operational work. AWS, Azure, or Google Cloud make more sense when the product needs their networking, scaling, security, or infrastructure options.

We choose the setup based on the limitation we are trying to solve. If the current platform still supports the application properly, adding more infrastructure does not make the product more production-ready.

From Code to Live: Build a Safer Release Pipeline

Production needs a clear release process. We keep the code in version control and run automated checks before a new version goes to staging. We test the main user flows there before the same release goes to production.

Staging and production should have separate credentials and configuration. A test payment should not charge a real customer, and test data should not end up in the production database. We set these environments up separately so developers don't have to manually change production settings when testing a release.

We also prefer smaller releases where possible. If an update breaks login, payments, or another important feature, fewer changes need investigating. We keep the previous working version available so the team can return to it if the problem cannot be fixed quickly.

Database changes need extra care. Rolling back the application does not automatically reverse a database migration. If a release changes a table, column, or data structure, we check how the old version of the application will work with that change. This helps us avoid a situation where we roll back the code, but it no longer works with the production database.

Lovable, Bolt or Replit: What Changes in Production?

The tool used to build the first version does not have to determine the final hosting setup. Once the application is ready for production, compare the available options with what the product actually needs.

Lovable, Bolt, and Replit all offer ways to publish applications, but you do not need to choose hosting based on the builder alone. Check what the app uses for its frontend, backend, database, storage, authentication, and background work. The hosting setup should support those parts without adding infrastructure the product does not need.

Step 4: Answer the Compliance Questions US Customers and Investors Will Ask

If your app stores customer data, processes payments, or works with health information, you need to know which compliance requirements apply before launch.

We review what data the app collects, where it is stored, which services receive it, and who has access. For US-focused products, SOC 2, HIPAA, PCI DSS, and state privacy laws are common requirements.

SOC 2

SOC 2 often comes up when a SaaS company starts working with enterprise customers. AICPA describes SOC 2 as an examination of controls related to security, availability, processing integrity, confidentiality, and privacy.

You do not need to complete SOC 2 before every product launch. If enterprise customers are part of the plan, it makes sense to start preparing early.

We check who has access to production, what activity is logged, and how changes reach the live app. Code should not be pushed directly to production from a personal account without a clear review and deployment process.

Keep records of these controls as well. If a customer asks about SOC 2 later, the company already has evidence of how it manages production access, releases, and other important processes.

HIPAA

A health app does not automatically fall under HIPAA. It depends on who the app works with and whether it creates, receives, stores, or sends protected health information on behalf of a covered entity or business associate.HHS explains which organizations and business associates are covered by HIPAA.

If HIPAA applies, we trace where that information goes. We need to review the database, hosting provider, file storage, and any AI service that receives patient information.

The agreements matter too. HHS guidance on cloud computing and HIPAA explains when a cloud service provider is considered a business associate and when a Business Associate Agreement (BAA) is required.

A provider describing its service as “HIPAA-ready” does not mean the application itself meets HIPAA requirements. The agreement, configuration, and way the service is used still matter.

PCI DSS

For card payments, we try to keep card details out of the application. Using a payment provider's hosted checkout reduces the amount of payment data your system has to handle.

Using a third-party payment provider doesn't remove all PCI DSS responsibilities. The PCI Security Standards Council explains the responsibilities that remain when you outsource payment processing.

We check how payments are integrated, what payment data reaches the application, and which parts of the setup remain your responsibility. Do this before accepting real card payments, not after customers have already started using checkout.

State Privacy Laws

US privacy requirements vary by state and don't apply to every business the same way. California's CCPA, for example, has specific conditions that determine which businesses fall under it. The California Attorney General provides an overview of the CCPA and consumer privacy rights.

Start with the data itself. We check what personal information the app collects, why it needs it, where it goes, and how long it stays. The privacy policy should describe what the product actually does.

User requests need to work in the application too. If someone has a legal right to request deletion, removing the account from the screen might not be enough. Their information could still exist in the main database or connected services.

We also identify what we must keep for legal or business reasons and set a retention policy for the rest.

This is a starting point, not legal advice. Compliance depends on the product, customers, data, contracts, and how the business operates. A qualified legal or compliance specialist should confirm the applicable requirements before launch.

Step 5: Plan Launch Day

Plan the launch before the deployment starts. We decide what is going live, who will watch the app, and what we will do if something breaks.

Keep the runbook short. The team should be able to open it during the launch and quickly see what to check, who is responsible, and when to roll back.

1. Stop Adding Features Before Launch

Stop adding features as the launch gets closer. Use the remaining time to fix important bugs, test the final release, and check the production setup.

If a fix is still needed, keep the change small and test it again. Do not add another feature just because it is almost finished.

2. Test the Final Release in Staging

Deploy the version you plan to launch to staging. Test sign-up, login, payments, permissions, and the other flows customers will depend on.

Then check the production setup. Confirm the domain and DNS, environment variables, API credentials, database migrations, payment settings, monitoring, and backups.

The code tested in staging should be the code you send to production. If something changes after the final test, test that change before releasing it.

3. Deploy While the Team Is Available

Choose a time when the people responsible for the release are online. If something breaks, the developer who knows the change should be available to investigate it.

If the app already has users, look at when traffic is lower and launch during a quieter period where possible. Avoid deploying just before everyone leaves for the day.

Someone should stay available long enough to make sure the new release is working normally.

4. Test the Main Flows in Production

Once the deployment finishes, run a short smoke test on the live app. Check that the app loads, sign in with a test account, and go through the most important actions. If the product accepts payments, check the live payment flow safely as well.

You do not need to repeat every test. The goal is to ensure the main parts of the product still work after the release.

Microsoft recommends smoke testing after deployment to confirm the application and infrastructure respond correctly.

5. Watch the App After Launch

Keep an eye on errors, response times, uptime, failed logins, payments, and the other metrics that matter to the product.

Compare them with what you normally see. If server errors suddenly increase or payments start failing after the release, investigate the change quickly instead of waiting for customers to report it.

Microsoft's safe deployment guidance also recommends watching application health during and after a rollout.

6. Decide When to Roll Back

Do not wait for something to break before deciding what counts as a failed release. Agree on the rollback conditions before deployment.

Customers can't log in, payments fail, private data is exposed, or server errors spike are clear reasons to stop and investigate.

Keep the previous working release available. Database changes need extra attention because rolling back the application does not automatically reverse a migration. Before launch, we check whether the previous version will still work if the database has already changed.

7. Decide Who Responds If Something Goes Wrong

Choose who will watch the alerts and who has the authority to stop or roll back the release. Another person should know enough about the setup to help if the main developer is unavailable.

Decide how customers will be updated as well. A visible problem might need a status page update, an in-app message, or an email to affected customers.

Once the main flows are working and production metrics look normal, the team can return to regular monitoring and maintenance.

Step 6: Keep It Healthy After Launch

After launch, we keep checking the parts of the app that change over time. Dependencies get older, traffic changes, costs increase, and new releases introduce new problems. The production setup needs to keep up with those changes.

Keep dependencies updated and address security patches as they appear. Tools like GitHub Dependabot help find outdated or vulnerable packages, but we still review and test updates before they reach production. An automatic update should not bypass the release process just because a tool created it.

We also keep watching errors, downtime, failed jobs, response times, and the parts of the product that matter most to users. Backups need checking as well. A backup running every day is useful only if the team knows that it can restore the data when needed.

When something breaks, the team should know who responds and who decides whether to roll back. After a serious incident, we find out what caused it and fix the problem, not just get the app back online.

Usage also changes the bill. More traffic can increase hosting, database, storage, bandwidth, and third-party service costs. AI features can get expensive as requests or tokens increase. We set usage or budget alerts where the provider supports them and review costs regularly so unexpected increases don't go unnoticed.

Lovable, Bolt, Cursor, Replit, and other coding tools can still be part of development after launch. What changes is how their code reaches production. Put the change in version control, review it through a pull request, run the automated checks, and test it in staging before releasing it. GitHub's pull request guidance explains how reviews and checks fit into this workflow.

Someone also needs to own the product's technical side. For a smaller app, that might be a technical founder or an engineer who supports it when needed. If development becomes more regular, the company might need additional engineers. A fractional CTO also makes sense when the team needs technical direction but is not ready for a full-time CTO.

The right setup depends on how much work the app needs after launch. Whoever oversees it should understand the code, have access to production systems, and be able to respond when something goes wrong.

How Long Does It Take, and What Does It Cost?

The time and cost depend on what we find when we review the app. If the code is in good shape, the work may be limited to security fixes, testing, monitoring, backups, and production setup.

More work is needed when authentication, permissions, payments, or the database have issues. Missing tests, several third-party integrations, and security or compliance requirements also affect the estimate.

For a smaller app that mainly needs production hardening, published estimates range from about 1 to 4 weeks. ProductionReady.co lists a 5–10 business day hardening sprint, while Resourcifi estimates 2–4 weeks for hardening a small app. Broader work takes longer. AppMatic puts production hardening and refactoring at around 4-10 weeks, while Resourcifi estimates 3-6 weeks when the core needs more substantial refactoring.

Cost varies widely with the app's condition. Published prices for smaller hardening work start around $4,500–$8,000. Broader production work is often higher: AppMatic publishes -40,000 for production hardening, while Resourcifi's estimates for deeper refactoring range from roughly $6,000 to $48,000, depending on the team and hourly rate.

These numbers help with early planning, but they are not fixed prices. We do not estimate an app based only on whether it was built with Lovable, Bolt, Replit, Cursor, or another tool. Two apps built with the same tool can need very different amounts of work.

We start with a technical review of the code, authentication, permissions, database, payments, integrations, tests, and infrastructure. It shows us what needs fixing before launch and what can wait. We then estimate the work based on what the app actually needs.

How CodingCrafts Takes Vibe-Coded Apps to Production

If you already have a working app, we start by reviewing what you have. We look at the code, architecture, database, integrations, security, hosting, and release setup to see what is ready for production and what needs more work.

We do not rebuild an app just because it was created with Lovable, Bolt, Replit, Cursor, or another coding tool. We first fix problems that could affect the launch. That might mean tightening permissions, securing exposed credentials, improving an unstable part of the code, adding tests, or setting up staging and deployment. We leave parts that already work well in place.

Before release, we test the main user flows, permissions, payments, integrations, and failure cases. We also set up monitoring, backups, and a clear deployment and rollback process so the team knows what to do if something goes wrong after launch.

CodingCrafts can work with your existing developers or take on the production work directly. After launch, we hand over the code, documentation, and runbooks your team needs to continue working on the product. If you still need support, we can help with maintenance, production issues, and future releases.

Your company keeps control of the code and production accounts. Your team can continue development internally or bring in another developer later without depending on the original builder setup.

If your vibe-coded app works but you are not sure whether it is ready for production, book a free 30-minute call with CodingCrafts. We can review where it stands and help you decide what needs to happen before launch.