Your Vercel project's Framework Preset can lie about itself

A few days after I shipped a Next.js site on Vercel, I checked the project's Framework Preset for the first time:

$ vercel project inspect eric-walters-site
...
Framework Settings
  Framework Preset    Other
  Build Command       `npm run vercel-build` or `npm run build`
  Output Directory    `public` if it exists, or `.`

"Other." Not Next.js. The project I'd been deploying to for four days, that was serving a working blog at a custom domain right then, thought it was hosting something else entirely.

Why deploys worked anyway

The reason was hiding in vercel.json. During day-one debugging of an unrelated 404 disaster, I'd added one line:

{ "framework": "nextjs" }

That field overrides the project's Framework Preset on every deploy. Vercel's build pipeline saw "Next.js" each time, ran the right build command, and routed the prerendered output correctly. The project-level setting was wrong, but never consulted.

Why it's a latent bug

vercel.json was holding the door shut. Delete the file. Open a fresh fork without it. Add vercel.json later for some unrelated config and forget the framework field. In any of those cases, Vercel falls back to the project's "Other" preset and you get day-one again — the build runs, the deployment is Ready, every URL 404s, and vercel inspect shows the giveaway:

Builds
  ╶ .        [0ms]

Same silent-fail mode. The patch had been load-bearing the whole time.

The fix is dashboard-only

There is no CLI command for this. vercel project --help lists protection, rename, web-analytics, and a handful of others — not framework. The fix lives in the dashboard:

Settings → General → Framework Settings → Framework Preset → Next.js → Save

After the change, vercel project inspect shows the corrected preset, plus a Next.js-aware Build Command (npm run build || next build) and Output Directory (Next.js default). The project finally describes itself accurately.

The bigger pattern

Any tool that lets you override a project default per-deploy is also letting you ship a project that lies about itself. The override is load-bearing until the project setting is fixed; once both agree, it drops to defense in depth — cheap insurance against future drift.

Most "works on my machine" deploy stories are this shape. One layer is correct, an upstream layer is wrong, and both have to fail in the same direction before anyone notices. The trick is not to trust that everything's fine because the surface looks fine. Read the project's actual settings. Make the root match the patch.

This is the third post in a row about Vercel deploy traps. The first was the silent-fail framework-detection bug; the second was the alias pinning that doesn't auto-rotate. Three feels like enough. Tomorrow I step away from the platform and start building the first AI workflow on top of it.