AI Founder OS
All modules

Module 6: Shipping to Production, for Real

Localhost does not count. Until real users can hit your URL or install your app from a real store, you have not shipped. This module covers the last mile for both web and mobile, including production parity, because surprises in production are expensive.

Key idea

Localhost does not count. Until real users can reach your URL, you have not shipped.

This module includes

  • Time: about 3 hours, depending on your DNS and deploy setup
  • You finish with: a live production deploy with monitoring, a health check endpoint, and a tested rollback plan
  • Start by running the pre-launch checklist, then deploy and verify before moving on
Operator loop: 6-step cycle from define to ship1Define goal2Draft spec3Execute4Handoff5Verify6Ship

Ship, monitor, fix. The production loop that keeps running.

Outcome

Your app is live. People can use it. You know when it breaks.

Deliverable

A production deployment with monitoring, a health-check endpoint, and a rollback plan you've actually tested.

Lessons

  • ·The pre-launch checklist: env vars, secrets, DNS, nothing skipped
  • ·Deploying to Vercel with full parity to your local environment
  • ·Writing a health-check endpoint and a smoke-test script
  • ·Monitoring that actually tells you something: errors, latency, uptime
  • ·What to do when production breaks at 2 AM
  • ·Post-launch iteration: small PRs, continuous proof, no big bangs
  • ·Domain setup, SSL certificates, and CDN basics
  • ·Using preview deployments as a real staging gate
  • ·Running database migrations in production without downtime
  • ·Webhook verification and why idempotency saves you
  • ·Incident response in practice: detect, isolate, fix, verify
  • ·Updating your Continuity Packet after launch so the next cycle starts clean
  • ·Deciding what to build next, and scoping it before you prompt

Exercises

  • ·Push to production. Run every smoke test. Fix what fails before you call it done.
  • ·Set up one alert (build failures or 5xx errors) and confirm it fires.
  • ·Simulate a bad deploy: revert it, watch the app recover, and write down what you did.

What good looks like

A real ship means live URL, working health check, and a rollback plan you have tested.
  • Production deploy verified with smoke tests on the live URL.

Proof Checklist

Proof
  • ☐App is live at your production URL with a valid SSL certificate
  • ☐Health-check endpoint returns 200
  • ☐npm run build exits clean
  • ☐git show --stat HEAD shows only the files you intended to ship
  • ☐git show --name-only HEAD matches your targets

Web lane (Vercel)

Most web deploys fail for boring reasons, not code bugs. Here is what to watch for when you push to Vercel or any similar platform.

  • ·Env vars matter more than you think. Your local .env.local is not on the server. Every variable your app reads must exist in your Vercel project settings. Missing one means a runtime crash that works fine on localhost.
  • ·Localhost lies to you. Local dev uses hot reload, skips middleware sometimes, and has different network behavior. If you only test locally, you will be surprised by things that work differently in production.
  • ·Preview deployments are your staging. Every PR gets its own preview URL on Vercel. Use it. Click around, test auth flows, check mobile layout. If it is broken in preview, it will be broken in production.
  • ·Build fails on Vercel? Check two things first: missing environment variables and missing dependencies. If your build passes locally but fails remotely, one of those two is almost always the cause.

Mobile lane (Expo + TestFlight)

If you are building a mobile app with Expo, the simulator is not the App Store. There are things that only surface when you build a real binary and install it on a real phone.

  • ·Simulator is not the App Store. Push notifications, camera permissions, deep links, and background fetch all behave differently on a real device. The simulator is for layout and logic. The real test is TestFlight.
  • ·Some changes require a native rebuild. Changing your app icon, adding push notification entitlements, or modifying native modules means you need to rebuild the native project (eas build or xcodebuild). An Expo OTA update will not cover it.
  • ·Entitlements and permissions differ. Your dev provisioning profile and your distribution profile have different capabilities. A feature that works in dev might fail in TestFlight because the entitlement was not added to the distribution profile.
  • ·TestFlight is your real proof pass. Before you submit to App Store review, install via TestFlight on a real phone. Check the icon, check permissions prompts, check that push works, check that deep links resolve.

Calm shipping flow for mobile

  1. 1. Run locally with Expo Go or a dev client. Fix what is broken.
  2. 2. Run in the iOS simulator (or Android emulator). Check layout and navigation.
  3. 3. Build for TestFlight (eas build, then eas submit). Install on a real phone.
  4. 4. Walk through the app on the real device. Test every permission prompt and flow.
  5. 5. If it passes on the real device, submit to App Store review.

Why production parity matters

The gap between your local environment and production is where bugs hide. The smaller that gap, the fewer surprises you get after launch.

  • ·Local is for iteration. Break things, try ideas, move fast.
  • ·Preview (or TestFlight) is for review. Catch env mismatches, layout issues, auth edge cases.
  • ·Production is for real users. If it is not verified in preview first, do not ship it.

Surprises in production are expensive. A five-minute check in a preview environment saves hours of debugging under pressure.

All modulesNext: Docs Kit