5 checks before your app goes live

Why it works on your computer and breaks live

While you build, your app runs on your own computer, often called local. Live means it’s on the internet for everyone. Locally, the app reads secret values from a file on your computer, sends people back after sign-in to an address that starts with localhost (the name your computer uses for itself), and talks to a test database full of your own data. A database is where your app stores its entries, such as accounts or notes.

When you publish, the app moves to a hosting service (a host for short) such as Vercel, a company that runs it on the internet for you. None of those quiet helpers come along by themselves. So launch-day errors often aren’t new bugs (programming mistakes) at all, but missing settings. The five checks below cover the ones that hurt most, in a sensible order. Most take a few minutes.

Check 1: Keys exist on the host, and secrets stay secret

Apps use environment variables: named settings kept outside the code, such as your database address or a key for a payment service. A key like that (often called an API key) works like a password your app uses to identify itself to a service. On your computer these values usually sit in a file called .env or .env.local. That file shouldn’t be uploaded with your code, for example to a repository on GitHub, the online storage for code. So the host doesn’t have it, and you enter the same values again in the host’s project settings.

Two details trip people up. On Vercel, a changed variable only applies to new deployments; a deployment is a version of your app uploaded to the host. So you publish again after changing one. And in Next.js, a common framework (a ready-made foundation) for these apps, any variable whose name starts with NEXT_PUBLIC_ is written into the code that every visitor’s browser downloads. A secret key must never carry that prefix.

1. 1Write down the name of every variable in your local .env file (names only, not the values). The file sits in your project’s main folder; if you can’t find it, ask your AI tool to list the names for you.
2. 2Open your host’s project settings; on Vercel, that’s Settings, then Environment Variables. Check that each name exists for Production, the live version of your app.
3. 3Check that no secret ends up in the browser. If your app uses Next.js (your AI tool can tell you), no secret name may start with NEXT_PUBLIC_. If it uses Supabase, a popular service for databases and sign-in, you’ll find two kinds of keys there under Settings, then API Keys: the publishable key may be public; the secret key (formerly the service_role key) never, because it bypasses every access rule.
4. 4Publish again after any change. On Vercel, go to Deployments, click the three-dot menu next to the newest deployment and choose Redeploy.

Keep secrets on the server and privileges small · From the Faber knowledge base

Check 2: Sign-in knows your live address

Links in emails, magic links (sign-in links without a password) and signing in with another account all send people away and back again. The sign-in service only sends them back to addresses on an allowlist; these return addresses are called redirect URLs. Supabase Auth, Supabase’s sign-in feature, starts with http://localhost:3000 as its Site URL, the default address people return to. If nobody changes it, sign-in works on your computer and fails live.

1. 1In Supabase, open Authentication and then URL Configuration.
2. 2Set the Site URL to your live address, for example https://yourapp.com.
3. 3Add your live address under Redirect URLs. If your host creates preview addresses (separate addresses for test versions), also add a wildcard pattern that covers all of them.
4. 4Sign in on the live site in a private (incognito) browser window, then sign out and sign in again.

Check the emails as well. Supabase’s built-in email service only delivers to members of your project team, and it’s currently limited to 2 messages an hour. For real users, connect your own email sending service through SMTP, the standard way of sending email, before launch; you’ll find the setting in Supabase under Authentication. Otherwise sign-up and password-reset emails simply won’t arrive.

Check 3: The live database is separate and has access rules

Your test data and your users’ data shouldn’t share a database. Supabase describes a setup with separate projects for production and for testing, so a broken experiment never touches real accounts.

The bigger risk is who can read what. A database is made of tables, and each row in a table is one entry, such as an account or a note. With Supabase, the app in the browser often talks to the database directly. Row level security (RLS) is the set of rules that decides, row by row, who may read or change data.

Without RLS, anyone who has the public key from your app can read and change the table; with RLS, that key reaches only what the rules allow. A rule that only checks “is someone signed in?” isn’t enough either: it lets every user see everyone else’s rows. The rule has to check ownership: does this row belong to the user who is signed in right now?

1. 1Check that you have two separate Supabase projects, one for testing and one for production. Ask your AI tool which environment variable on your host shows that the live app is connected to the production project.
2. 2In Supabase, open the SQL Editor and ask your AI tool for the short query that lists whether RLS is enabled on each table. The “rowsecurity” column must say “true” for every table.
3. 3Ask your AI tool to list every table with its rules and explain each one in a single plain sentence.
4. 4Sign in with a test account (user A) and create something. Then sign in with a second test account (user B) and try to find it. User B must see nothing of A’s.

Row level security with an ownership rule · From the Faber knowledge base

Check 4: Walk the real flow on the live address

The version that ran on your computer isn’t the one visitors get. Test the published site itself, the way a stranger would, not the preview inside your builder (the tool you build the app in).

1. 1Open the live address in a private browser window and on your phone.
2. 2Sign up as a brand-new user with an email address you haven’t used before, and confirm it through the link in the email.
3. 3Do the one main thing your app exists for, from start to finish.
4. 4Do it wrong on purpose: leave a form empty, type nonsense, cancel halfway. You should see a clear message, not a blank page.
5. 5Look at a screen that has no data yet, like a new account’s empty list. It should tell the person what to do next.
6. 6Repeat the main flow with a second account and confirm neither account can see the other’s data.

Check 5: A way back, and a way to see errors

Something will go wrong eventually. What matters is whether you notice, and whether you can undo it.

A way back for the app. A rollback brings back an earlier version of your app. Vercel’s Instant Rollback points your domain (your app’s address) back to an earlier live version in a few clicks. On the free Hobby plan you can return to the previous deployment; paid plans can pick any earlier one. A rollback swaps the app’s code, not your data or your environment variables.

A way back for your data. Supabase’s paid plans include automatic daily backups (safety copies of your data). The free plan doesn’t, and Supabase recommends exporting your data regularly yourself. Know which case you’re in before real users arrive.

A way to see errors. When a user hits a problem, you won’t see their screen. Vercel’s Logs section shows what happened on the server, with server errors marked in red. On the Hobby plan, logs are kept for one hour, so look soon after something breaks.

1. 1Find the rollback button on your host and note where it is. On Vercel, Instant Rollback is on your project’s overview page.
2. 2In Supabase, open Database, then Backups, and check which backups your plan includes. If there are none, ask your AI tool to walk you through exporting a copy today.
3. 3In your Vercel project, open Logs, cause a harmless error on purpose, and find it there. Your AI tool can tell you how to cause one in your app.

Let your AI tool build the checklist, with proof

Your AI tool can read your actual code, which no generic list can. Ask it to check your specific app, and insist on proof for every item. Anything it can’t prove stays open until you’ve checked it yourself.

Before I publish this app, create a pre-launch checklist for this exact project. Don’t change any code yet.

Cover at least:
1. Every environment variable the app needs, where it’s used, and whether it’s secret. Flag any secret that could reach the browser or is saved in the repository.
2. Sign-in: which Site URL and Redirect URLs I need for my live address, [your live address]. Also check how sign-up and password-reset emails are sent.
3. The production database: is it separate from testing, does every table have row level security, and does each rule check that the row belongs to the current user?
4. The main user flow on the live address, including error states, empty states and a second user who must not see the first user’s data.
5. How I roll back a bad release, how my data is backed up, and where I can read error logs.

For each item, show proof: the file and line, the exact setting I should look at, or a test I can run myself. Mark anything you couldn’t check as UNVERIFIED instead of guessing.