afterbuild/ops
Vercel deployment developer

Vercel Deployment Developer & Fix Expert

Non-technical founders moving an AI-built app from Lovable or Bolt to Vercel hit the same wall: env vars not set correctly, build scripts wrong, domains pointing at the old host, and cold starts killing UX. Afterbuild Labs fixes in two to five days from $299.

By Hyder ShahFounder · Afterbuild LabsLast updated 2026-04-17

Why deploying AI apps to Vercel is harder than it looks

Lovable, Bolt, v0, and Replit preview environments hide most of the configuration a Vercel production deploy demands. The preview auto-wires env vars, uses its own domain, skips DNS, and runs the build inside the platform container with no config surface exposed. A founder clicks deploy and it works. Then they try to migrate to their own Vercel project and half the things the preview handled silently are now their responsibility — and the AI tool never wrote them down.

A Vercel deployment developer treats each of those hidden things as a work item. The env vars have to be re-entered with awareness of which are NEXT_PUBLIC and which are server-only. The build command has to match the lockfile the AI tool produced. The domain has to be added in DNS with the right record type. The SSL has to provision. The OAuth redirect URIs have to be updated at Google Cloud and at Supabase. Any of those missed and the deploy either fails outright or ships with a subtle security or routing bug.

On top of the platform move, AI tools frequently generate code that worked in Next.js 15 but trips Next.js 16 defaults. The caching model changed, dynamic route handlers signed differently, and middleware tightened. A Vercel deploy fix on a Next 16 upgrade always turns up at least two code-level regressions the AI tool never noticed.

Env var patterns: client vs server, preview vs production

The Vercel env vars fix is the most common Vercel deployment developer engagement we see. The three rules to internalize: NEXT_PUBLIC variables get bundled into the client JS at build time, server-only variables stay on the server, and preview deploys can have their own values that differ from production. AI tools routinely violate all three. A NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY ends up in a bundle. A server-only variable is read from a client component and comes back undefined. A preview deploy inherits production data because the env was never scoped.

Our rescue builds a spreadsheet of every env var, its scope, and its intended value per environment, then sets each on Vercel. We rotate anything that leaked, audit the source code for NEXT_PUBLIC references against the spreadsheet, and run a fresh production build to pick up the corrected values. The Vercel deploy succeeds once the env vars match the code and the scope matches the environment.

Broken — secret leaked via NEXT_PUBLIC
// lib/supabase.ts — ships to the browser
import { createClient } from '@supabase/supabase-js';

// NEXT_PUBLIC prefix bundles this into client JS
export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!
);
Fixed — client uses anon, server uses service
// lib/supabase-browser.ts
import { createBrowserClient } from '@supabase/ssr';
export const browser = createBrowserClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

// lib/supabase-admin.ts (server only)
import { createClient } from '@supabase/supabase-js';
export const admin = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!  // no NEXT_PUBLIC
);

Build errors from Next.js 15 to 16 upgrades

The Next.js 16 upgrade changed defaults that AI tools have not fully caught up to. Route handlers now require explicit cache tags. Middleware signatures tightened. Dynamic route behavior flipped. A build that succeeded on Next 15 will surface half a dozen errors on first bump. A Vercel deployment developer reads the upgrade guide in node_modules/next/dist/docs, runs the codemod, and hand-fixes the rest — particularly the cases the codemod cannot handle automatically.

Common failure modes we see: an app router route using the Next 15 implicit cache that now returns stale data, a middleware that destructures request headers in a way Next 16 rejects, and a page component that relied on automatic revalidation and now needs explicit revalidate exports. We fix each, re-run typecheck and build, and verify the preview deploy before promoting to production.

Broken — wrong build command for Next 16
{
  "scripts": {
    "build": "next build --no-lint"
  },
  "engines": {
    "node": ">=14"
  }
}
// Next 16 requires Node 20+. Vercel build fails with
// cryptic "invalid package" error.
Fixed — pinned node and explicit build
{
  "scripts": {
    "build": "next build",
    "lint": "next lint",
    "typecheck": "tsc --noEmit"
  },
  "engines": {
    "node": ">=20.11"
  }
}
// Vercel uses Node 20, build runs next build,
// CI runs typecheck separately before deploy.

Domain, SSL, and redirect setup

Setting up a custom domain on Vercel is simple in theory and full of edge cases in practice. A Vercel domain setup usually touches five systems: DNS at the registrar, Vercel project settings, Supabase Site URL (if using Supabase Auth), OAuth redirect URIs at Google Cloud (for SSO), and any Stripe webhook endpoints pointed at the old host. Miss any one and the deploy looks fine on the root page and fails on sign-in or payment.

We run the full pass during a Vercel deployment rescue: add the apex and www, configure the www-to-apex redirect in Vercel, verify SSL provisioned correctly (Vercel does this automatically once DNS propagates), update Supabase Site URL, add the new redirect URI in the Google Cloud console, and update Stripe webhook endpoints. Then we run a real sign-in, a real checkout, and a real OAuth flow against the new domain before closing the ticket.

Cold starts and edge function strategy

A Vercel cold start fix balances three levers: runtime choice, region pinning, and bundle size. Edge runtime has tiny cold starts (tens of milliseconds) but limited Node APIs and no filesystem. Node runtime has more capability but larger cold starts (hundreds of milliseconds to seconds). Region pinning places the function in the same region as the database to cut round-trip time. Bundle size affects cold start because Vercel has to fetch and parse the code before invoking the handler.

Our Vercel edge function debug pass profiles the real-world latency with the Vercel Observability tab, then picks the right lever per route. A critical checkout route runs on edge in the same region as the Stripe webhook. A heavy report route runs on Node with extended timeout. Most AI-built apps default every route to the same runtime, which is rarely the right choice. See our Vercel deployment expert hub for the deeper profiling and tuning work.

CI/CD and preview deploys for solo founders

Vercel preview deploys are one of the most underused features on the platform. Every PR gets its own URL, which means non-technical reviewers can click a link and test changes before merge. For solo founders, this is the closest thing to a staging environment that costs nothing extra. The trick is scoping the data plane so previews do not mutate production — either with a branch Supabase project, a Neon branch database, or a Stripe test mode pointed at a separate webhook.

We wire a minimal GitHub Actions workflow alongside the preview deploy: typecheck, lint, and tests run before Vercel starts the build. A failing check blocks the deploy. This is the baseline every production Vercel app needs and the one AI tools almost never scaffold. See our deployment and launch service for the full rollout.

Our Vercel deploy rescue process

Every Vercel rescue follows the same six-step sequence. Triage starts within 24 hours and the written diagnostic lands in 48.

  1. 01
    Audit env vars across preview, production, and development

    Confirm every required variable is set on each environment. Distinguish server-only from NEXT_PUBLIC. Rotate anything accidentally exposed.

  2. 02
    Fix the build command and framework preset

    Set the framework preset to Next.js, confirm the install and build commands match the lockfile, and pin the Node version via package.json engines.

  3. 03
    Wire the custom domain and SSL

    Add the domain, apply the DNS records, set the www-to-apex redirect, and verify Supabase Site URL plus OAuth redirect URIs match the new host.

  4. 04
    Tune cold starts and runtime

    Pick edge or Node runtime per route, shrink bundles, and pin the function region close to your database. Set spend caps on image optimization and analytics.

  5. 05
    Enable preview deploys with scoped data

    Configure preview deploys to use a branch Supabase project or a Neon branch. Every PR gets a fresh data plane that cannot mutate production.

  6. 06
    Add CI checks and a rollback plan

    GitHub Actions runs typecheck, lint, and tests before deploy. Document the Vercel rollback command so a bad release reverts in under a minute.

When to use Vercel vs Netlify vs Railway

Vercel wins for Next.js apps. It owns the framework, ships new features first, and the integration with Next.js is deeper than any alternative host. Netlify is a reasonable alternative for static-heavy sites with light dynamic work, and the forms and identity products are useful out of the box. Railway is better when you need a long-running server, persistent WebSockets, cron jobs, or a Postgres instance colocated with the app.

Most AI-built apps we rescue land on Vercel. The small number that migrate to Railway do so because the app has a realtime layer or a worker that does not fit serverless. A Vercel production migration is the right default; we only suggest Railway after we have confirmed the app actually needs it.

DIY vs Afterbuild Labs vs hiring a Vercel specialist

Three paths to a clean Vercel deployment. Pick based on how close you are to launch and how much downtime risk you can absorb.

DimensionDIY with AI toolAfterbuild LabsHire Vercel specialist
TurnaroundDays to weeks of prompt loops48h diagnostic, 2-5 day fix2-6 weeks to start
Fixed priceNo — time sink on the founderYes — from $299$150-220/hr, no cap
Env var scope auditUsually missedFull audit plus rotationIncluded
Next.js 15 to 16 upgradeNot attemptedCodemod plus hand fixesUsually included
Domain, SSL, redirectsPartialFull five-system passIncluded
Cold start tuningNot attemptedPer-route runtime choiceDepends on scope
CI/CD and rollback planNot scaffoldedGitHub Actions plus rollback docsUsually included
FAQ

Hire Vercel developer — FAQs

How much does Vercel cost for a production app?+

The Hobby tier is free for personal, non-commercial projects. Pro starts at $20 per seat per month and includes production deployments, team collaboration, 1TB of edge transfer, and 1000 GB-hours of serverless execution. Most AI-built apps we deploy run comfortably on Pro under $50 a month. The bill creeps up when image optimization, edge functions, or analytics are turned on without caps — we configure spend limits during the Vercel deploy fix.

Why did my NEXT_PUBLIC env var leak the wrong value?+

Any variable prefixed NEXT_PUBLIC_ is bundled into the client JavaScript at build time. If the value differs between environments, Vercel uses the value that was set when the build ran. AI tools often put secrets behind NEXT_PUBLIC by mistake, or switch the prefix halfway through and leave the stale value in a previous preview. Rotate any exposed secret, re-audit every NEXT_PUBLIC reference, and trigger a fresh production build after the changes.

How do I point a custom domain at Vercel?+

Add the domain in the Vercel project, copy the A record or CNAME Vercel shows, and apply it in your DNS provider. Apex domains need an A record; subdomains get a CNAME pointing at cname.vercel-dns.com. SSL provisions automatically once DNS propagates. The gotchas are the www-to-apex redirect (set it in project settings), Supabase Site URL (update it separately), and OAuth redirect URIs (update those at Google Cloud and in your auth provider).

How do I migrate a Next.js 15 app to Next.js 16 on Vercel?+

Next.js 16 changed defaults around caching, server components, and route handlers. Run the official codemod, read the upgrade guide in node_modules/next/dist/docs, and handle the breaking changes one at a time. The common failure surfaces are dynamic route handlers, the switch to explicit cache tags, and middleware signatures. A Vercel deployment developer pair is helpful here because Next 16 upgrades on AI-built apps almost always uncover latent bugs the generator introduced.

Vercel vs Netlify vs Railway — which should I pick?+

For Next.js apps, Vercel is the default. It owns the framework and ships new features first. Netlify is a reasonable alternative for static-heavy sites with form handling. Railway is better when you need a long-running server, cron jobs, or a Postgres instance colocated with the app. Most AI-built apps fit Vercel; a small number hit edge cases where Railway wins, usually when WebSockets or persistent workers are in play.

How do I fix slow cold starts on Vercel?+

Cold starts on Vercel serverless functions average 100-500 ms but can climb to 2-3 seconds on first hit after a deploy. Three levers move the number: smaller bundle size (tree-shake imports), region pinning (pick the closest to your database), and edge runtime for latency-sensitive routes. Vercel also offers fluid compute in 2025, which keeps functions warmer at the cost of a slightly higher bill. We pick based on traffic pattern during the Vercel cold start fix.

How do I wire Vercel and Supabase together?+

Install the Vercel-Supabase integration from the Vercel marketplace — it injects NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY automatically. For the service role key, add it separately on Vercel as a non-public variable. Use the pooler connection string (port 6543) for serverless routes and the direct connection (port 5432) for long-lived processes. If you are running migrations in CI, use a separate short-lived connection that bypasses the pooler.

What is a typical Vercel deploy fix timeline?+

Two to five business days from $299 covers the common failures: env var propagation, build command fix, Next.js version bump, domain plus SSL plus redirect setup, and a first look at cold starts. Full production migrations off Lovable or Bolt run one to two weeks. A written diagnostic ships in 48 hours so you know scope before committing. Every engagement is led by Hyder Shah, no handoffs.

Next step

Get a Vercel deployment developer on your repo this week.

Send the repo and the Vercel project URL. A written diagnostic lands in 48 hours; the Vercel deploy fix ships in two to five business days from $299. Hire a Vercel deployment developer who has migrated dozens of AI-built apps from preview to production and will stay through the first deploy after handoff.