Getting it online

Getting a site onto the real internet used to be a whole discipline. Now it's about fifteen minutes, once, and then it's automatic forever. This is genuinely the easiest part of the whole process, and it's worth doing on day one rather than week six.

What deploying actually means

Right now your app runs on your computer at localhost:3000, which nobody else can reach. Deploying means putting a copy on a computer that's always on and connected to the internet, with a proper address.

The modern version, which is what you'll use:

1. Your code lives on GitHub.
2. A host (Vercel) watches that repository.
3. Every time you push, it automatically builds your app and puts the new version live.
4. If the build fails, it keeps the old version up and emails you.

That last point is worth pausing on: a broken build doesn't break your live site. The failed version simply never goes live.

Deploying to Vercel

1. Push your project to GitHub.
2. Sign up at vercel.com with your GitHub account.
3. "Add New Project", pick your repository, press Deploy. For a Next.js app it needs no configuration.
4. A minute later you have a live URL like your-app-abc123.vercel.app.

That's it. From now on, git push means "deploy".

Environments

You'll hear three words a lot:

Your own domain

1. Buy one — Cloudflare, Porkbun and Namecheap are all fine, and VentraIP or Crazy Domains if you want an Australian registrar for a .com.au. Expect about A$20–25/year. Cloudflare sells them at cost, which is the cheapest honest option.
2. In Vercel: Settings → Domains → add your domain.
3. Vercel shows you the DNS records to add. Copy them into your registrar's DNS settings.
4. Wait. Usually minutes, occasionally a few hours.

HTTPS — the padlock — is set up automatically and free. You don't have to do anything, and you should never pay anyone for an SSL certificate for a project like this.

Before you put it in front of anyone

A short, honest checklist. Not comprehensive — the things that actually embarrass people.

Works

• Sign up with a fresh email you've never used. Does the whole flow work for a brand-new user?
• Do the main thing your app is for, on a real phone, on mobile data rather than your wifi.
• Click every link. Check for any that go nowhere.
• Make a second account and confirm it cannot see the first account's data.

Doesn't embarrass you

• Page titles say something real, not "Create Next App".
• The favicon isn't the framework's default.
• No lorem ipsum, no test data, no "Coming soon" placeholders you forgot.
• Sharing a link somewhere shows a sensible preview card.

Won't get you in trouble

• No secrets in GitHub. Check again.
• RLS on, on every table, verified in the dashboard yourself.
• A privacy policy, if you collect any personal data at all — which you do, if you have accounts.
• An email address people can actually reach you at.

You'll know if it breaks

• Error tracking installed (Sentry has a free tier; setup is genuinely ten minutes).
• Analytics of some kind — Vercel Analytics or Plausible. Otherwise you're guessing about everything.
• Database backups on, if you're on a Supabase plan that has them.

After launch

Two habits, both cheap:

• Watch the first ten users closely. Errors, analytics, and if you can, ask them to share their screen while they use it. You'll learn more in twenty minutes of watching than a week of speculating.
• Keep deploying small changes. Small and frequent is far safer than big and rare — when something breaks, you know exactly which change did it.

I'm a non-technical founder deploying for the first time. My project is [describe: Next.js app, Supabase, etc.] and it currently runs on my machine.

Walk me through deploying to Vercel, one step at a time, waiting for me to confirm each step.

Cover:
1. Making sure the project is ready (and what would make a build fail)
2. Connecting the GitHub repo
3. Every environment variable I need to set, and where each value comes from
4. What to check immediately after the first deploy
5. Adding a custom domain, including what the DNS records mean
6. How to tell whether it actually worked, beyond "the page loads"

For each step tell me what success looks like, and the most likely thing to go wrong. Also tell me which of my environment variables are safe to expose to the browser and which absolutely aren't — and how the naming convention indicates that.

I'm about to put this in front of real users for the first time. Audit the whole project as if you were a senior engineer signing off a launch for a non-technical founder.

Check and report on:
1. Anything that would leak data between users
2. Secrets: anything committed, anything exposed to the browser that shouldn't be
3. Missing environment variables that would break in production but not locally
4. Error handling: what happens when things fail, and would the user see something sensible?
5. Empty, loading and error states on every screen
6. Mobile: anything that breaks between 360px and 768px
7. Basic legal hygiene: privacy policy, cookie consent, terms, contact details
8. Whether I'd find out if this broke at 3am

Give me a prioritised list: must fix before launch, should fix this week, can wait. Be honest about the must-fix items — I'd rather delay a day than have a bad first week.

Help me set up error tracking and analytics so I actually know what's happening on my live site. I'm non-technical and cost-sensitive.

1. Recommend tools with genuinely usable free tiers, and tell me what each answers that the others don't.
2. Walk me through installing error tracking, step by step.
3. Show me how to trigger a test error deliberately so I can confirm it's working end to end.
4. Tell me how to set up alerts so I hear about real problems but don't get spammed.
5. Tell me the five numbers I should look at each week, and what a bad value for each would mean.

Keep it minimal. I want the smallest setup that means I'm never the last to know.