Take your Lovable, Bolt or Replit app to production

The first stage is a review, done before a price for the fixes is agreed. We read the code, the database schema and its access rules, the environment variables and the hosting setup. We sign up as two different users and try to read each other's data. We follow the payment flow from checkout to the webhook that grants access.

From you we need access to the repository or a code export, the database project and the hosting, plus a list of what the app must do on launch day. Tell us which parts the builder generated and which were changed by hand. If the app cannot export code, as with Bubble, we say so on the first call: that is a rebuild, and it is quoted as one.

You get a written report in plain language. Each issue says what could go wrong, how likely it is and what it costs to fix, sorted into three groups: fix before real users, fix soon after launch, and can wait. You decide what goes into the fixed price. During the fixes you get a weekly note and a link to a test environment with the changes applied.

Beyond sign-in and payments, the review looks for:

• Secrets that reached the browser, the repository or the logs
• Database tables with no access rules, or rules that allow everything
• Public endpoints with no rate limits
• Backups, and whether anyone has ever tried a restore
• Personal data stored or logged where it does not need to be

AI builders produce code that works when you click through it. The problems sit in what nobody clicks: a table any signed-in user can read, an API key shipped to the browser, a webhook anyone can call, an admin page protected only by a hidden link. The app looks finished, and the first sign of trouble is a customer seeing someone else's data.

We fix these where they belong. Access rules move into the database, with row-level security, so one customer's records cannot be read even when a screen has a bug. Secrets move into the hosting provider's secret store and are replaced if they were ever exposed. Payment webhooks are verified by signature, a repeated event changes nothing, and access is granted from the provider's records, not from a success page the browser can reach on its own.

Then we write tests for the paths that matter: sign-up, access between accounts, checkout and the change of plan. They run in a pipeline before every deploy, so the next change, by a person or by a prompt, cannot quietly undo a fix.

Our published work includes this kind of rework. In the AI product generator, generated SVG is sanitised before it is stored, every record is scoped to its owner with row-level security, and we later reworked the codebase and its payments. In our car import marketplace, internal fees never reach the browser, and CI checks the build, the parser, the webhook and image URLs on every change.

The production app lives in a normal repository on your account, with protected branches and reviewed changes. Hosting, the database, the payment provider and error tracking are under your company. You get the tests and the pipeline, and a short runbook: how to deploy, roll back, restore the database and replace a leaked key.

The review report stays useful after launch. Each issue is marked fixed, deferred or accepted, and the deferred ones keep their risk rating, so you can plan them into a later stage or hand them to your own developer.

Sometimes a different service fits better:

• The review shows most of the code has to go? We will say so, and MVP development rebuilds it on a sound foundation.
• The prototype is really an internal tool built on an Airtable base? See Airtable migration.
• The risky part is an AI feature giving wrong answers? AI integration covers testing and checks for model output.