Module 7: Ship to Production
Lesson 5

Production Checklist — Security, mobile, monitoring

You Built Something Real

Take a breath. You have a real application, on a real server, at a real address. Before you share it widely, walk through this checklist. None of it is hard — it's the difference between "a thing I made" and "a thing I'm proud to put my name on."

Work through it once now. You can ask Claude Code to help with any item you're unsure about.

Security

This is the part you don't want to get wrong. The good news: if Claude Code built your app, most of it is already handled. Verify anyway.

Secrets and Keys

  • .env.local is listed in .gitignore so it never reaches GitHub.
  • No keys or secrets are hardcoded anywhere in your code — they all come from environment variables.
  • Every environment variable your app needs is set in Vercel's dashboard.

Not sure? Ask Claude Code:

Check my project for any hardcoded secrets or API keys that should be in environment variables instead. Also confirm .env.local is in my .gitignore.

Database (Supabase)

  • Row Level Security (RLS) is enabled on every table.
  • RLS policies are correct — each user can only see and edit their own data.
  • Your frontend uses the anon key, never the service_role key.
  • Supabase's Site URL and Redirect URLs point to your production domain.

RLS is the single most important security setting in your app. Without it, anyone could potentially read everyone's data. If you're not 100% sure yours is right, ask Claude Code to audit your tables and policies before you launch.

Authentication

  • Login works at your production URL.
  • New users can sign up.
  • Log out works.
  • Protected pages send logged-out visitors to the login screen.

The User Experience

Your app works for you because you know how it's supposed to behave. A first-time visitor doesn't. These checks catch the rough edges they'd hit.

Error and Empty States

  • Forms show helpful error messages, not just "Something went wrong."
  • Loading spinners or skeletons appear during database fetches and form submits.
  • Empty screens have friendly guidance, not just a blank void.

Mobile

Most of your visitors will arrive on a phone. Open your live URL on yours right now.

  • Does it look reasonable? Is the text readable?
  • Are buttons big enough to tap with a thumb?

If it looks broken, hand it to Claude Code:

Make the app responsive for mobile screens. It should look good on a phone (375px wide) as well as on desktop.

The Full Walk-Through

Pretend you're a brand-new user and do the whole loop:

  • Sign up as a new user.
  • Do the main thing your app is for (add a task, create a post, whatever it is).
  • Refresh the page — your data is still there.
  • Log out, then log back in — data still there.
  • Try to reach another user's data — it should be blocked.

That last one is your RLS check in real life. If you can see someone else's data, stop and fix it before sharing.

Performance and Stability

Build Locally First

Before you rely on Vercel to catch problems, catch them yourself:

npm run build

If this finishes with no errors, you're in great shape. If it fails, fix the errors before pushing — the message names the file and line, and Claude Code can take it from there.

Check the Console

Open your browser's developer tools (F12, or right-click → Inspect) and look at the Console tab while using your app.

  • Red errors need fixing.
  • Yellow warnings are usually fine to ignore.

Polish the README

Add a link to your live app at the top of your README.md so anyone who finds your repo can try it:

## Live Demo

[yourapp.com](https://yourapp.com)

Want it to look sharp? Ask Claude Code to polish the whole README.

Your Workflow From Here

You've done the hard one-time setup. Shipping changes is now genuinely this simple:

# make your changes, then:
git add .
git commit -m "Describe what you changed"
git push

# Vercel deploys automatically in ~1–2 minutes.

After pushing, glance at your Vercel dashboard to confirm the deploy succeeded. If it fails, click into it to read the log.

When Production Breaks

It happens to everyone. Here's the calm, repeatable recovery process:

  1. Read the Vercel log. Dashboard → your project → Deployments → click the failing one → View logs.
  2. Test locally. Does it work at localhost:3000? If yes, it's a production-only issue — almost always environment variables.
  3. Roll back. Vercel lets you instantly revert to any previous working deploy: Deployments → pick an older one → "…" menu → Promote to Production. This gets users a working app right now while you investigate.
  4. Ask Claude. Paste the error log and ask for the fix.

Knowing you can roll back in one click is what lets you ship without fear. A broken deploy is a five-minute inconvenience, not a disaster.

Keeping an Eye on Things

For most apps, Vercel's built-in analytics is plenty. Turn it on:

  • Vercel → your project → Analytics → Enable.

It shows how many visitors you get, which pages they view, and how fast your app responds.

When you want to go further:

  • Sentry (free tier) — alerts you when real users hit JavaScript errors.
  • Vercel Speed Insights — deeper performance metrics.

Look at What You Did

It's worth stopping to notice this. You may have started with no coding experience. And yet, you:

  • learned to use Claude as a genuine thinking and building partner,
  • installed Claude Code and got comfortable in the terminal,
  • built a real web app with modern tools (Next.js, TypeScript, Tailwind),
  • learned Git, so your work is versioned and safe,
  • connected a real database with authentication and per-user data,
  • and deployed to production with a custom domain, HTTPS, and auto-deploy.

This is not a "fake it" achievement. Real code. Real database. Real server. Real domain. The gap between you and "a developer" is narrower than you thought — because you now know the workflow, the tools, and how to lean on an AI to close any gap that's left.

What to Build Next

You got to a deployed, working product. Here's where to go from here:

Improve this app — work through your feature backlog, polish the design, add error tracking, watch your analytics.

Level up — learn a bit more about how Next.js works under the hood, get comfortable reading your own code, then build a second app (it'll be much faster).

Think like an owner — if this is a real product: what would you charge? Who are your first ten users? What single feature would make them pay?

Share it — post it on LinkedIn or X, send it to people it helps, and write about what you learned. Others standing where you started would love to hear it.

Summary

  • Run the security, UX, and performance checks before you share — especially RLS.
  • Your ongoing workflow is just git add . → git commit → git push → done.
  • If something breaks, roll back in one click and fix it calmly.
  • Turn on Vercel analytics; reach for Sentry when you want more.
  • You shipped something real. That genuinely deserves celebrating.