Shipping to Production

You have been building. The app works on your machine, the demo wowed a friend, and the itch to put it out into the world is real. This is the moment a lot of solo builders stall — not because the code is broken, but because "going live" feels like a different discipline with its own dark arts: DNS, servers, secrets, payment webhooks. Good news: this is exactly the kind of mechanical, well-documented work that AI is best at. Your job is to direct. Their job is to type the commands.

This chapter walks the whole last mile, from a working local app to a real URL people can pay you through.

Pick a Host and Deploy

For most vibe-coded apps, you do not need a server you babysit. Modern platforms take your code and give you a live URL in minutes. The common choices:

Static sites and frontends: Cloudflare Pages, Vercel, Netlify, GitHub Pages.
Full-stack apps and APIs: Cloudflare Workers, Vercel, Render, Fly.io, Railway.
Heavier backends: a container platform or a small VPS.

The right move is to tell the AI what you built and let it recommend. Try: "This is a Next.js app with a Postgres database. I want the cheapest reliable host with a generous free tier. Give me the deploy steps and a config file."

Once you have picked one, deploying is usually a couple of commands:

# Example: Cloudflare Workers via Wrangler
npm install -g wrangler
wrangler login
wrangler deploy

# Example: Vercel
npm install -g vercel
vercel --prod

Let the AI generate the platform config (wrangler.toml, vercel.json, etc.) and explain any errors the first deploy throws. First deploys almost always throw something — a missing build command, a wrong output directory. Paste the error back and ask for the fix. Two or three rounds and you are live on a temporary URL.

Custom Domains and DNS

A *.workers.dev or *.vercel.app URL is fine for testing, but you want your own name. The flow:

Buy the domain (Namecheap, Cloudflare Registrar, Porkbun — pick one).
Point its DNS at your host. This usually means adding a CNAME or A record, or changing the domain's nameservers entirely.
Add the domain in your host's dashboard and let it issue an SSL certificate automatically.

DNS is the single most confusing part for beginners, mostly because of jargon and propagation delays. Have the AI translate. Ask: "My domain is registered at Namecheap and I'm hosting on Cloudflare Pages. Walk me through exactly which records to add, what values, and how to verify it worked." Then verify the result yourself with a quick check rather than just refreshing the browser:

dig yourdomain.com
nslookup yourdomain.com

DNS changes can take anywhere from minutes to a day to propagate. If it is not live immediately, that is normal — wait and recheck before assuming something is broken.

Environment Variables and Secrets

Your code needs API keys, database URLs, and tokens. These must never be committed to your repo. Two rules carry you a long way:

Keep secrets in a .env file locally, and make sure .env is in your .gitignore.
Set the same values as environment variables in your host's dashboard (or via CLI) for production.

# .env  (local only — never commit this)
DATABASE_URL=postgres://localhost:5432/app
STRIPE_SECRET_KEY=sk_test_xxx
SESSION_SECRET=change-me

# Set the production equivalents on the host
wrangler secret put STRIPE_SECRET_KEY
vercel env add STRIPE_SECRET_KEY production

Maintain a committed .env.example listing the names (not values) of every variable, so future-you and the AI both know what the app expects. If you ever paste a secret into a chat or commit one by accident, treat it as compromised and rotate it immediately.

Wiring Up Payments

If you want to get paid, the standard path for a solo builder is Stripe (or Lemon Squeezy / Paddle if you want them to handle sales tax for you). The mechanics are repetitive and well-documented, which makes them ideal to delegate. The pieces you need:

A checkout flow — Stripe Checkout is the fastest; it hands you a hosted payment page.
A webhook endpoint so your app learns when a payment actually succeeded. This is the part beginners skip and then wonder why orders never get fulfilled. Never trust the redirect alone; trust the webhook.
A way to store entitlements — mark the user as paid in your database.

Ask the AI to scaffold all three and explain the webhook signature verification, since that is the one security-sensitive step. Test everything in Stripe's test mode with their test card numbers before flipping to live keys. Do not skip the test-mode dress rehearsal.

Monitoring and Error Tracking

Once people use your app, you need to know when it breaks — ideally before they tell you. The lightweight starter kit:

Error tracking: Sentry catches and groups exceptions with stack traces. A few lines to install.
Uptime monitoring: a free pinger (UptimeRobot, Better Stack) emails you when the site goes down.
Logs: know where your host keeps them (wrangler tail, the Vercel dashboard, etc.) so you can investigate.

Have the AI add Sentry and wire a basic health-check endpoint. The goal is not enterprise observability — it is simply not finding out about an outage from an angry tweet.

Performance and Caching

Slow apps lose users and rank worse in search. You do not need to micro-optimize on day one, but grab the cheap wins:

Serve static assets through a CDN (most hosts do this automatically).
Cache expensive responses and database queries that do not change often.
Compress and lazy-load images; ship less JavaScript.
Run Lighthouse in Chrome DevTools and feed the report to the AI for prioritized fixes.

Ask: "Here's my Lighthouse report. Give me the three changes with the biggest impact for the least effort." Let measurement, not guesswork, drive what you optimize.

Pre-Launch Checklist

Before you announce anything, walk this list. Have the AI help you verify each item rather than trusting your memory.

After You Launch

Shipping is the start, not the finish. The first version is a hypothesis; real users are the experiment. Watch your error dashboard, read every message, and ship small fixes fast. Resist the urge to rebuild everything at the first sign of friction — patch the sharp edges, double down on what people actually use, and let the rest wait.

The most powerful habit here is a tight loop: notice a problem or an idea, describe it to the AI, ship the change, watch the result. Because the mechanical work is delegated, you can iterate in hours instead of weeks. That speed — not any single feature — is the real advantage of building by vibe. You are live. Now keep going.

Cost Safety: CLI vs API

One last bill can ambush you after launch, and it rarely comes from hosting — it comes from a metered AI API. The tools you code with (Claude Code, Cursor, and friends) are usually a flat-rate subscription, where an extra prompt costs nothing. But the moment your shipped app calls a raw AI API or SDK, you're billed per token, per request, with no ceiling. A buggy retry, an unbounded batch job, or an agent that loops can turn a $0 idle bill into a four-figure surprise overnight. That's "bill shock" — the most common way a solo launch goes wrong financially.

Before you flip to live, cage every paid API the same way you caged your secrets:

Set a hard spend cap in the provider dashboard — a real ceiling, not just an alert.
Develop on the flat-rate CLI; reserve the metered API for the production path that genuinely needs it.
Rate-limit your own calls (concurrency and requests per minute) and watch the usage dashboard in the first days after launch.
Use cheap/small models for bulk work and test on tiny inputs first.
Never ship an unthrottled loop that calls a paid API. Bound every loop.

Add this to your pre-launch checklist next to "all secrets set": every paid API has a hard cap and a throttle.