Services · App to production

Take your Lovable app
to production.

I take Lovable, Bolt, Replit and Base44 apps to production. Your app works in the demo; I audit the code, fix whatever exposes data or money first, harden auth, the database and payments, deploy it properly and hand it over. Audit first, fixed scope, one senior engineer and no agency layer.

When it is time

  • Paying users, or about to have them

    Once money changes hands, or a second company's data sits in the same tables as the first, a bug stops being an annoyance and becomes a refund or a breach.

  • Every prompt fixes one thing and breaks another

    The builder rewrites files you did not ask about, and the credits go on asking for the same fix a third time.

  • A security questionnaire you cannot answer

    A bigger customer or an investor asks who can read which data, and nobody has read the code.

  • Payments that do not match access

    A customer charged twice for one upgrade, or one who paid and still sees the trial banner.

If the app has a handful of users, no payments and no personal data worth stealing, keep prompting. A founder who can get screens into shape should not pay a developer to do it more slowly.

How it runs: audit first, fixed scope

  1. 1. Audit

    3-5 working days

    Read-only access to the code, the database, the hosting and Stripe. I map every table, policy and endpoint, then run checks that produce evidence: two-account data probes, secret scans over the bundle and the git history, and a billing reconciliation. Exposed data or keys are fixed the same day.

  2. 2. Fix list

    End of the audit

    A written report with each finding, its evidence, its severity and the fix, plus a fixed price for the work. You decide part by part what is kept, fixed or rebuilt, and you can stop here.

  3. 3. Hardening

    1-3 weeks

    Row-level security on every table, secrets moved server-side and rotated, auth edge cases closed, Stripe webhooks that are signed and processed once, rate limits on signup, login and any AI endpoint, and tests on signup, checkout and the core workflow.

  4. 4. Deploy

    Final week

    GitHub as the one home of the code, CI that runs the tests before anything merges, a staging environment with its own database, error tracking on the money paths, one-click rollback, and one real restore from backup.

  5. 5. Handover

    Last day

    A runbook for incidents and restores, a note on which parts are safe to keep prompting, a walkthrough call, and every credential in your accounts, not mine.

What the audit checks

  • Who can read which data

    Supabase row-level security that is off, or on with a policy that allows everything. Probed per table as two test users, never assumed.

  • Secret keys

    Service-role, Stripe or OpenAI keys in the browser bundle or the git history. Anything prefixed VITE_ or NEXT_PUBLIC_ is public. The fix is rotation, not deletion.

  • Login and accounts

    Password resets, email changes, redirect URLs, sessions, and roles users can edit themselves.

  • Database

    No migrations, previews writing to the production database, and backups nobody has restored.

  • Payments

    Access granted on the success page, webhooks processed twice, and paid accounts that never left the trial.

  • AI features

    Model calls with no per-account limits, prompts that leak, and retrieval that is not scoped to the account.

The full checklist, an audit's first afternoon in tool calls and the keep-or-rebuild table are in the prototype-to-production blueprint.

Pricing

Fixed after the audit, quoted on the call. Every app hides a different fix list, so there is no price list for this. The audit has a fixed scope and is quoted on the free 30-minute call; its report ends with a fixed price for the fixes, and you choose which ones to buy.

When the audit shows the work is closer to a rebuild, it is scoped as MVP development instead, with your current app as the specification.

Built, shipped and kept running

I have shipped six products end to end, and what matters here is the part after launch. The Caldra AI case study walks through a scheduling agent that reads the inbox, and the four things that broke in production before I caught them.

For what an audit looks like on an app built with Lovable, the field story follows a composite founder from her first paying customer to a clean report. More builds are in the case studies.

Frequently asked questions

How long does it take to make a Lovable app production-ready?

Most take two to four weeks. The audit runs three to five working days, and anything that exposes customer data or a secret key is fixed the day it is found. Hardening, tests and a proper deploy pipeline take one to three weeks after that, depending on the fix list. A redesign of billing or the data model takes longer.

Is my app secure enough for paying customers?

You only know once someone checks. The screens are usually fine; the risk sits in the rules. On a Supabase backend, row-level security policies decide who can read which rows, and the public anon key ships to every browser by design. The first audit test signs in as two test accounts and tries to read each other's data. If anything comes back, that is fixed before anything else.

Do you fix the login and the database, or rebuild them?

Usually fix. Auth problems are mostly edge cases: email changes, password resets, redirect URLs that accept any domain, and a role column users can edit themselves. On the database I add a baseline migration, a separate staging project and a tested restore from backup. A part is rebuilt only when the audit shows it cannot hold your rules, such as a data model with no room for teams or roles.

Can you fix Stripe payments that give the wrong people access?

Yes, it is one of the most common findings. Many apps switch an account to paid on the checkout success page, so a user who closes the tab early pays and gets nothing, and a copied URL can unlock the plan for free. I move access onto signed Stripe webhooks, process each event once, and add a nightly check that compares who has paid with who has access.

Where will my app be hosted afterwards?

Wherever fits, in accounts you own. Lovable and Bolt apps usually keep Supabase, with the front end on Vercel or Netlify and separate production and preview environments. An app on Replit's or Base44's own database and hosting can stay there if the audit finds it safe, or move to your own Postgres and hosting when you need staging, backups you control or a security questionnaire answered.

What happens to my Lovable project? Can I keep building in it?

It stays yours and keeps working. Lovable syncs with GitHub in both directions, so you can keep prompting for screens. The parts that hold your rules, such as policies, migrations, webhooks and edge functions, sit behind CI tests that fail if a regenerated file weakens them. Every change arrives as a pull request with a preview, so prompting stays fast and cannot quietly break production. Bolt and Replit projects work the same way once the code lives in GitHub.

How much does it cost to take my app to production?

There is no price list, because the cost depends on what the audit finds. The audit has a fixed scope and is quoted on the free 30-minute call. It ends with a written fix list and a fixed price for the fixes, so you choose what to pay for, and you can stop after the report and take it to anyone.

Related: MVP development · Prototype-to-production blueprint · Custom software development