What to do after building with Lovable: a five-step roadmap

After building with Lovable, do five things in order: export the code to GitHub, audit the security defaults, replace happy-path billing with real plumbing, choose a hosting posture on purpose, and decide who owns operations. Each step below says what to check and why.

The app works. Lovable did what the demos promised: you described a product and got one, with a database, auth screens, and a URL. Every guide on the internet covers that part. This one covers the week after, which is where the interesting decisions live.

Step 0: decide what this is

Be honest before you spend a weekend hardening anything. Is this a demo to validate an idea, a tool for yourself, or a product strangers will pay for? The first two are done; ship the link and enjoy. Everything below is for the third case, because paying strangers change the rules: they bring their data, their expectations, and their right to be furious when things break.

Step 1: export to GitHub, today

Lovable's best feature isn't generation; it's that the code is yours. Connect the GitHub sync and get your repo out. Do this even if you plan to keep building inside Lovable, for three reasons:

• It's your backup against platform changes, pricing changes, or the tool having a bad day.
• It opens the two-tool workflow: keep prompting in Lovable, or move to Cursor or Claude Code when a change needs a surgeon instead of a slot machine.
• Code review, even casual, becomes possible. You can't audit what you can't see.

Expect the code to be React + Vite + Tailwind with Supabase behind it, more verbose than a human would write, and organized the way a fast intern organizes a desk. That's fine. It runs, and it's standard enough that any tool (or developer) can pick it up.

Keep it that way. The test of a good tool, and a good platform, is that the repository stays ordinary after they touch it: your commits and theirs land in the same history, and nobody reasserts a template over your changes. That is the rule Solo holds itself to, and it is a fair one to hold every tool to.

Step 2: the security audit you didn't prompt for

Generated apps ship with a recurring set of holes, and Lovable's Supabase-centric stack has one that towers over the rest: row-level security. If RLS is off (or written permissively so the demo would work), every user can potentially read every other user's rows through the public API. This is not hypothetical; open or permissive RLS is a recurring finding whenever people scan vibe-coded apps.

The 30-minute audit:

• RLS enabled on every table with user data, with policies you've read out loud
• No secret keys in the repo (search for sk_live, service_role, rotate anything you find)
• Permission checks on the server, not just hidden buttons in the UI
• Edge functions validate their inputs instead of trusting the client

The full hole-by-hole walkthrough is in our vibe coding security guide. Do not skip this step and then connect Stripe.

Step 3: real money needs real plumbing

Lovable will happily wire a Stripe checkout for you, and the happy path will work. Production billing is the unhappy paths: renewals, declines, upgrades, refunds, all arriving as webhooks that must be verified and handled idempotently, with feature access gated server-side off your database rather than off "they visited the success page." Our monetization guide walks the whole thing.

Step 4: choose your hosting posture

You have three sane options, in escalating order of ownership:

• Stay on Lovable hosting. Right answer for validation and early traction. One button, done. You trade away deploy control, rollback, and infra visibility.
• Vercel or Netlify + managed Supabase. The common middle: your repo deploys on push, previews per branch, and the database stays where Lovable put it.
• Your own cloud. When customers get serious (or enterprise-shaped), you'll want infrastructure you govern: your AWS account, your database, your backups, deploys with rollback. This is the destination; the only question is when. ListMyCar.ai runs this way, with its AWS infrastructure defined in its own repository so the business can deploy it into its own account. The case study shows how its deploys, and the failed attempts, are recorded.

The mistake isn't picking any one of these. It's not knowing which one you're on and what it can't do.

Step 5: the operations nobody generated

Here's the part that surprises everyone. Once real users arrive, the product becomes the smaller half of the job. Uptime needs watching. Errors need a destination other than the browser console. Backups need testing. Dependencies need patching. Marketing needs to happen weekly, forever, or the funnel quietly dies. Support needs answering at breakfast.

None of this appears in the Lovable canvas because none of it is code. It's the production layer, and it's recurring rather than one-time. The production readiness checklist covers what to have in place before launch. The harder question is who keeps it in place afterwards: you, a checklist, or software.

The pattern, and the shortcut

Zoom out and the road from Lovable to a real business is: own your code, close the security gaps, wire real billing, graduate your hosting, and stand up operations. Each step is documented, none is hard alone, and together they're the "other 95%" that separates a working app from a working company.

Solo is the business layer under your app. A standard stack with auth, Stripe webhooks, and AWS deploys with rollback, then the recurring operations: monitoring, incidents, marketing, with your approval on what matters. Keep building with Lovable, Cursor, or any tool you like. The repo stays yours. Join the waitlist →