Bonus track

Shipping real apps

The CS tracks build understanding over months. This page is what you need today if real people are about to use something you built. Work through it before launch, and again every time you add something big.

Challenge: Put the ship steps in order

Tap the steps in the order they should happen.

Git branches, pull requests and CI

Never work directly on main. Make a branch for each change (git switch -c fix-login), commit small steps, push it, and open a pull request (PR). A PR is a page showing exactly what changed, where you (or a teammate, or an AI reviewer) can read it before it goes live.

CI (continuous integration) is a robot that runs your checks on every PR: install, type-check, lint, test, build. If anything fails, you see a red X before it reaches users. GitHub Actions is free for public repos and an easy place to start.

Watch the AI: AI agents love to "helpfully" edit 30 files at once. Keep them on a branch and review the diff before merging.

Branch protection on main: require a PR and passing checks before merging.
A CI workflow that runs the build and tests on every pull request.
Small PRs with clear titles. One change per PR.
Commit before every big AI prompt, so you can always roll back.

Environment variables and secrets

API keys, database passwords and tokens are secrets. They belong in environment variables (a .env file locally, and your host's settings in production), never in your code or Git history.

Know which keys are safe in the browser. Anything in frontend code is public: anyone can open DevTools and read it. Variables prefixed NEXT_PUBLIC_, VITE_ or PUBLIC_ end up in the browser. A Supabase "anon"/publishable key is designed to be public (if RLS is on); a "service role" or secret key must never be.

Watch the AI: AI tools sometimes paste a key straight into a file "to make it work", or put a server key in a client component.

.env is in .gitignore.
No secret keys in frontend code or public env variable prefixes.
Separate keys for development and production.
If a key ever got committed, rotate it (make a new one and revoke the old). Deleting the file is not enough.

Authentication and authorization

Authentication proves who someone is (login). Authorization decides what they can do. Use a proven auth provider (Supabase Auth, Clerk, Auth0, your framework's official library) instead of rolling your own password storage.

The golden rule: check permissions on the server or in the database, every time. Hiding a button in the UI is decoration, not security.

Watch the AI: Generated code often checks if (user) (logged in?) when it should check if (user.id === record.owner_id) (allowed?).

Every API route and server function checks who is calling and whether they are allowed.
Passwords are never stored by you in plain text (let the auth provider handle it).
Sessions expire and logout actually works.
Admin-only actions are enforced on the server, not just hidden in the UI.

Database migrations

A migration is a small, numbered file describing one change to your database structure ("add a phone column to agents"). They live in Git with your code, run in order, and let you rebuild the database exactly on any machine.

Clicking around in a database dashboard to change tables in production is how environments drift apart and how data gets lost.

Watch the AI: Ask the AI to write the migration as a file, read it, then apply it. Never let an agent run raw DROP statements against production.

Every schema change is a migration file in the repo.
Migrations are tested on a dev/preview database before production.
Back up production before risky migrations.
Destructive changes (dropping columns or tables) are done in steps, after the code no longer uses them.

Row Level Security and security basics

If your frontend talks directly to the database (common with Supabase and Firebase), the database itself must enforce who can see which rows. In Postgres that's Row Level Security (RLS): rules like "a user can only read rows where user_id = auth.uid()".

Then cover the basics from the OWASP Top 10: validate all input on the server, use parameterized queries (never glue user text into SQL), rate-limit logins and forms, and keep dependencies updated.

Watch the AI: The most common serious flaw in vibe-coded apps: RLS disabled, or "fixed" by allowing everything when a query failed.

RLS is enabled on every table exposed to the client.
No policy that just says true for everyone unless the data is truly public.
Test it: logged in as user A, try to read and edit user B's data. It must fail.
Input is validated on the server (e.g. with a schema library like Zod).
File uploads are restricted by type and size, with private storage for private files.

Testing

You don't need 100% coverage on day one. Start with the things that would hurt most if they broke: sign-up and login, payments, permissions, and your core feature.

Unit tests check logic (pricing math, date handling). Integration tests check your API plus database. One or two end-to-end tests (Playwright) click through the main flow in a real browser.

Watch the AI: Watch for AI "fixing" a failing test by changing the test instead of the code.

Tests run in CI on every PR.
At least one end-to-end test of the critical path (sign up → do the main thing).
A test that proves a user can't access someone else's data.
When you fix a bug, add a test that would have caught it.

Deploys

Modern hosts (Vercel, Netlify, Cloudflare, Render) deploy automatically from Git: every PR gets a preview URL, and merging to main deploys production. Use the preview to check changes before they go live.

Know how to roll back. Every good host keeps previous deployments, so you can instantly switch back to the last working version.

Watch the AI: Agents sometimes deploy straight from a local machine or skip the checks. Let the pipeline be the only way to production.

Production deploys only from main, after CI passes.
Preview deployments for every PR.
You know how to roll back in under two minutes.
Error monitoring (e.g. Sentry) or at least readable logs in production.
A custom domain with HTTPS, and email sending (SPF/DKIM) set up if your app sends mail.

Official docs worth bookmarking

GitHub flowThe branch → PR → merge workflow, explained by GitHub.
GitHub Actions docsSet up CI for your repo.
The Twelve-Factor AppClassic principles for config, secrets and deploys.
Supabase: Row Level SecurityHow to write RLS policies, with examples.
OWASP Authentication Cheat SheetAuth done right.
OWASP Top 10The most common web app security risks.
Vercel: Environment variablesManaging secrets per environment.
PlaywrightEnd-to-end testing in real browsers.