No server to rent. No deploy ceremony. You push code; a URL goes live. And the trap nobody warns you about: the deploy can be green and your users still see the old app.
01 · the scene
"Vercel says it deployed. The fix isn't there."
The build went green. The dashboard said Ready. The code on the live URL was still the broken version. Same commit, same project — the change just… wasn't reaching the screen.
my-day — Vercel deploy log
▲ VercelBuilding… ✓ Compiled successfully ✓ Deployment Ready — Production (opened the live URL. still the old version. hard-refreshed. still old.)
Neill51% · the terrain
"It said Ready. Green check. I trusted that — of course I did, it's a giant green checkmark. So why was my phone still showing the broken thing?"
Claude49% · the execution
"A successful deploy means the server has the new code — not that your device is showing it. A cached page, a stale env var, or a phone still holding the old install will all lie green. I should've said 'green ≠ reached you' before you went hunting for a bug that wasn't there."
02 · the why
Vercel removes the server. That's the whole pitch.
Hosting a web app used to mean renting a computer, keeping it alive, patching it, and copying files onto it by hand. Vercel deletes all of that. You connect your repo once; from then on every git push gets built and put on a live URL — no machine to babysit. It's the host built for Next.js, so the apps you make slot straight in.
▲
Push = deploy
git push → live URL
Connect the repo once. Every push builds and ships automatically. No file-copying, no SSH, no ops.
⌥
Preview URLs
one per branch
Every branch gets its own private live link. Test the real thing before it touches production.
◷
Vercel Cron
scheduled jobs, free-ish
Run a job on a timer — my-day's daily flag processing runs on Vercel Cron, no separate server.
The catch to internalize early: "deploy succeeded" and "the change reached the user's device" are two different events. Between them sit caching, environment variables that didn't carry, and zombie installed web-apps holding old code. A green checkmark proves the first, never the second.
03 · predict it
Deploy is green. The fix isn't live. Why?
Build succeeded, dashboard says Ready, but the live URL still shows the old version. What's actually going on?
Not it. The build genuinely succeeded — trust the green. The gap is after the deploy: what's between Vercel's server and your eyes?
Exactly. The server has the new code; your view doesn't yet. A CDN/browser cache, a missing-on-prod env var, or a phone still running an old installed copy all serve stale. First move when "deployed but not showing": check the cache and confirm the env vars actually carried — don't go debug code that's already fixed.
04 · the walkthrough
From repo to live URL, in four frames.
Import Git repo
step 1Connect your repo to a Vercel project once. Vercel auto-detects Next.js — near-zero config.
git push → Building
step 2Push to your branch. Vercel builds it automatically and gives that branch a preview URL.
Promote to Production
step 3Merge to your main branch → Vercel ships it to the production URL. Same flow, no extra steps.
Settings → Env Vars
step 4Set every secret/config in the Vercel dashboard — your local .env does not travel with the push.
05 · prove it · gate
Teach it back to unlock the payoff.
Same rule as always: answer it right, or the module isn't done.
Vercel shows a green "Deployment Ready." Why is that not proof your users are seeing the new version?
// one correct answer unlocks Module 14
Not the reason. The build is real and the deploy is real — think about everything that sits between Vercel's server and the user's screen.
That's it. "Deployed" is a fact about the server; "I can see it" is a fact about the delivery path — cache, env vars, the device's cached copy. When a fix won't show, suspect delivery before you re-debug the code. Module unlocked. ↓
the durable idea
Push to deploy is the gift; "green ≠ reached the user" is the discipline. The checkmark proves the server got it — not that the screen did.
06 · factory payoff
⊘ locked — pass the teach-back to claim this piece of the factory
A starter vercel.json + the deploy-didn't-reach-me checklist.
A real vercel.json you can drop into a Next.js project — a daily Cron entry wired the way my-day's runs, plus the deploy/security headers worth having from day one. Paired with a checklist that walks the exact "it deployed but I don't see it" hunt in order, so you never again debug code that's already fixed.