Scale · founder · 8 min read

From Prototype to Production: Your Post-MVP Checklist

The things you need to do before your AI-built app goes live — security, performance, backups, and the stuff founders always skip.

Published March 1, 2026 ·

deploymentproductionfounderschecklist

There’s a specific moment every AI-built app reaches: it works, your test accounts do everything right, you want to show real users. This is the prototype-to-production gap, and it’s where most non-technical founders either skip critical steps or don’t know what they don’t know.

What follows is a checklist with enough context to understand why each item matters. Some of these will take 10 minutes. Some will take a day. None are optional if you’re handling real users and real data.

The Actual Difference Between a Prototype and a Production App

A prototype is an app where things can break without consequence. A production app is one where they can’t — because real users are trusting you with their accounts, their data, and sometimes their money.

The gap isn’t mostly about features. It’s about what happens when something goes wrong: a user enters bad data, a payment fails, a database query is slow, someone tries to access data they shouldn’t. Prototypes handle these cases badly or not at all. Production apps handle them gracefully.

AI builders produce working prototypes by default. The steps below turn them into production apps.

Authentication and Authorization

Is your auth actually protecting anything?

AI builders wire up authentication quickly — sign up, log in, log out. What they often miss is authorization: making sure logged-in users can only access their own data.

Test this yourself. Create two accounts. Log in as User A, find a record URL (like /dashboard/projects/42), log out, log in as User B, and navigate to that same URL. Can User B see User A’s data?

If yes, you have a serious problem. Fix it before you go live.

Row-level security in Supabase

If you built with Lovable or any tool using Supabase, check whether row-level security (RLS) is enabled on your tables.

Go to your Supabase dashboard → Table Editor → click any table → check the RLS tab. If it says “RLS disabled,” any authenticated user can query any row in that table via the Supabase client. This is the default.

Turn on RLS for every table that holds user data, then add policies:

-- Example: users can only select their own rows
CREATE POLICY "Users can view own data"
ON public.projects
FOR SELECT
USING (auth.uid() = user_id);

Lovable’s prompts can generate these policies for you if you ask:

“Add row-level security policies to the projects table so users can only read, update, and delete their own rows.”

Admin routes

If your app has an admin panel, make sure it’s protected by a role check — not just by being hard to find. Security through obscurity isn’t security.

Database Setup

Backups

Supabase’s free tier includes Point-in-Time Recovery on paid plans only. On the free tier, you get daily backups with a 7-day retention window.

If you’re handling data that would genuinely hurt to lose, upgrade to Supabase Pro ($25/month) or implement your own backup strategy (there are simple cron-based solutions that export to an S3 bucket).

Environment variables

Your Supabase keys and any API secrets should be in environment variables, not hardcoded in your codebase. Lovable handles this, but if you’ve exported your code or built with Bolt.new, double-check that no secrets are sitting in your committed files.

If you’ve accidentally committed an API key: rotate it immediately, then remove it from your code.

Database migrations

As your app evolves, you’ll change your database schema. Get in the habit of making changes through migrations (Supabase has a CLI for this) rather than clicking around in the dashboard. Migrations are repeatable and reversible. Dashboard clicks are neither.

Performance

Image optimization

Unoptimized images are the single most common performance problem in AI-built apps. A 4MB product photo that should be 80KB will make your app feel broken on mobile.

If you’re using Astro, use the built-in <Image> component — it handles optimization automatically. For apps built with Lovable or other full-stack tools, make sure images are compressed before upload, or use a service like Cloudinary’s free tier for automatic optimization.

Core Web Vitals

Run your app through PageSpeed Insights before launch. A score below 50 on mobile will hurt your SEO and make users leave. Common fixes: image optimization, removing unused JavaScript, lazy-loading below-the-fold content.

Loading states

Every async action should have a loading state. Buttons that trigger API calls should disable and show a spinner while the request is in flight. Without this, users click twice, create duplicate records, and wonder if anything worked.

Custom Domain and SSL

Get off the builder’s subdomain

yourapp.lovable.app is fine for testing. It’s not fine for a real product. A custom domain signals that you’re serious and it’s required for custom email sending (see below).

Set up your custom domain through your builder’s settings, then point your DNS records accordingly. Lovable, Bolt.new, and most hosts make this straightforward.

SSL is automatic but verify it

Your hosting provider will provision an SSL certificate automatically. Verify it worked by visiting your domain over https:// — you should see the padlock. If anything shows “not secure,” do not launch until you’ve resolved it.

Error Monitoring

Without error monitoring, you’ll learn about bugs when users email you — and only the ones who bother to email. Most just leave.

Sentry has a generous free tier and integrates with Lovable-generated apps. Set it up in a day:

Create a free account at sentry.io
Create a new JavaScript/React project
Add the Sentry SDK and initialize it with your DSN

Now you’ll receive an email every time an uncaught error occurs in production, with a stack trace and the user’s session context. This is invaluable.

Payments: Test Mode vs. Live Mode

If your app processes payments, you are almost certainly still in Stripe test mode. Test mode payments don’t move real money. This is obvious in retrospect, but several founders have launched with test mode active and wondered why no revenue showed up.

To go live:

In your Stripe dashboard, switch from “Test mode” to “Live mode” (toggle in the top right)
Copy your live publishable and secret keys
Update your environment variables with the live keys
Submit your account for activation if you haven’t (Stripe needs basic business info to enable live payments)

Test your checkout flow with a real card for a small amount before announcing your launch.

Legal

Privacy policy and terms of service

You need both before going live. This is non-negotiable if you’re collecting any personal data (which means: if you have user accounts, you are).

You don’t need a lawyer for a first version. Tools like Termly, Iubenda, or Clerky generate reasonable boilerplate that you can customize. Read what you’re publishing — understand what you’re committing to.

Add links to both in your footer and during signup.

If any of your users are in the EU or UK, you need a cookie consent banner if you’re using analytics or marketing cookies. Google Analytics without consent is a GDPR violation. Either use a consent management tool (Cookiebot, Osano) or switch to a privacy-first analytics tool that doesn’t require consent (Fathom, Plausible).

Operations

Transactional email

Your app sends emails — signup confirmation, password reset, notifications. These should come from a domain you control, not a shared builder domain. Set up Resend or Postmark (both have free tiers) and verify your domain’s DNS records (SPF, DKIM). Without this, your emails land in spam.

Status page

When your app goes down (it will), users will assume the worst without communication. A free status page via Instatus or Betteruptime takes 20 minutes to set up and makes you look professional when things break.

A way to contact you

An email address or a simple contact form. Don’t hide it. Users who can contact you when things go wrong are users who don’t leave and post angry reviews.