DEV Community: Carlos Oliva Pascual

The Production Deployment Checklist Senior Devs Never Skip (2026)

Carlos Oliva Pascual — Wed, 27 May 2026 12:18:32 +0000

Most outages aren't caused by bad code. They're caused by good code deployed in the wrong order.

Senior developers don't rely on memory before a deploy. They run a checklist — every single time, even for a one-line change.

Here's the exact checklist, and why each step exists.

Why checklists exist

Pilots don't skip the pre-flight checklist because they've flown 10,000 hours. They do it because they've flown 10,000 hours — enough to know exactly what happens when you skip a step.

The same principle applies to production deploys. Every step in this checklist exists because someone, somewhere, had an outage from skipping it.

The 12-step checklist

#	Check	Why it matters
1	Env vars validate at build	Silent `undefined` in prod = 3 AM alert
2	Migrations run BEFORE deploy	New code can't see old schema
3	No `drizzle-kit push` in prod	Applies changes without migration files
4	Feature flag OFF for new features	Ship code off, turn on after smoke test
5	Error monitoring configured	First error hits Sentry, not a user
6	Health check endpoint responds	Load balancer needs `/api/health`
7	Rate limiting on auth endpoints	Login brute-force = account takeover
8	Secrets in env manager, not code	Rotating a secret ≠ a new deploy
9	Stripe webhooks tested	Webhook signature fails silently
10	Rollback plan ready	Know the previous deploy hash
11	Smoke test the critical path	Log in → do the main action → verify
12	Alert channel exists	Errors go somewhere humans actually see

Step 1 — Env vars validate at build time

If you're using process.env.THING directly, your app will start and fail at runtime when THING is undefined. The error happens in production, at 2 AM, in front of your first real user.

With t3-env, the build fails — which is exactly what you want:

// src/lib/env.ts
import { createEnv } from '@t3-oss/env-nextjs'
import { z } from 'zod'

export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    CLERK_SECRET_KEY: z.string().min(1),
    STRIPE_SECRET_KEY: z.string().min(1),
    STRIPE_WEBHOOK_SECRET: z.string().min(1),
    SENTRY_DSN: z.string().url(),
  },
  client: {
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
  },
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    CLERK_SECRET_KEY: process.env.CLERK_SECRET_KEY,
    STRIPE_SECRET_KEY: process.env.STRIPE_SECRET_KEY,
    STRIPE_WEBHOOK_SECRET: process.env.STRIPE_WEBHOOK_SECRET,
    SENTRY_DSN: process.env.SENTRY_DSN,
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: process.env.NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY,
  },
})

If STRIPE_WEBHOOK_SECRET is missing from Vercel, next build fails. You catch it before a single user sees anything.

Pro tip: Add every new env var to env.ts the same moment you add it to .env.local. Never add one without the other.

Step 2 — Migrations run before deploy, always

This is the most important rule in production database management.

❌ WRONG:   Deploy code → Run migrations
✅ CORRECT: Run migrations → Deploy code

Why: during a Vercel deployment, both the old and new versions of your app run simultaneously for a few seconds. The new code expects the new schema. If you deploy code first, new code breaks on the old schema during that window.

With Drizzle:

# Never in production
npx drizzle-kit push

# Always in production
npx drizzle-kit generate   # creates the migration file
npx drizzle-kit migrate    # applies it to the database

Step 3 — `drizzle-kit push` is banned in production

push applies your schema changes directly, without generating migration files. It's designed for development — fast iteration, no noise.

In production, it means:

No audit trail of what changed
No ability to roll back a migration
Risk of accidental data loss with no undo

Add this rule to your CLAUDE.md and your team's internal docs:

## Database rules
- Never use `drizzle-kit push` in production
- Always `generate` then `migrate`
- Migration files are committed alongside the code that requires them

Step 4 — Feature flags for every new feature

The classic failure mode:

❌ Ship → Users see broken feature → Emergency rollback
✅ Ship (flag OFF) → Smoke test in production → Turn flag ON → Gradual rollout

With Vercel Edge Config:

import { get } from '@vercel/edge-config'

export async function isNewDashboardEnabled(userId: string) {
  const config = await get<{ enabledUserIds: string[] }>('new-dashboard')
  return config?.enabledUserIds.includes(userId) ?? false
}

New feature ships disabled. You test it in production with your own account. When it works, you enable it for 5% of users. If something breaks at 5%, you turn the flag off — no rollback, no deploy, 10 seconds to fix.

Step 5 — Error monitoring before go-live

The key word is before. Your error monitoring must be live and verified before you ship the code that might error.

// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.1 : 1.0,
  beforeSend(event) {
    if (process.env.NODE_ENV === 'development') return null
    return event
  },
})

Verify it works before deploying: throw a test error manually, confirm it shows up in your Sentry dashboard.

Step 6 — Health check endpoint

// src/app/api/health/route.ts
import { db } from '@/lib/db'
import { sql } from 'drizzle-orm'

export const runtime = 'nodejs'

export async function GET() {
  try {
    await db.execute(sql`SELECT 1`)
    return Response.json(
      { status: 'ok', db: 'connected', ts: Date.now() },
      { headers: { 'Cache-Control': 'no-store' } }
    )
  } catch {
    return Response.json(
      { status: 'error', db: 'disconnected' },
      { status: 503 }
    )
  }
}

This checks the actual database connection, not just that Next.js started. Set up an uptime monitor (BetterStack, UptimeRobot, Checkly) to hit /api/health every 60 seconds.

Step 7 — Rate limiting on auth endpoints

Auth endpoints are the most targeted on any public app. Without rate limiting, a brute-force attack on your login endpoint is trivial.

// src/app/api/auth/login/route.ts
import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '15 m'),
  analytics: true,
})

export async function POST(request: Request) {
  const ip = request.headers.get('x-forwarded-for') ?? 'unknown'
  const { success, reset } = await ratelimit.limit(`login:${ip}`)

  if (!success) {
    return Response.json(
      { error: 'Too many attempts. Try again later.' },
      {
        status: 429,
        headers: { 'Retry-After': String(Math.ceil((reset - Date.now()) / 1000)) },
      }
    )
  }

  // proceed with auth logic
}

Step 8 — Secrets in your env manager, not in code

Three rules:

Never in code — not even encrypted, not even in a comment
Never in git — .env.local is gitignored for a reason
Rotate without deploying — secrets change in Vercel's env dashboard, not in a commit

// Wrong — rotating this requires a code change + deploy
const stripe = new Stripe('sk_live_abc123')

// Right — rotating means updating the var in Vercel, nothing else
import { env } from '@/lib/env'
const stripe = new Stripe(env.STRIPE_SECRET_KEY)

Step 9 — Stripe webhook signature verification

If you don't verify the signature, anyone can POST to your webhook endpoint and trigger fake payment events.

// src/app/api/webhooks/stripe/route.ts
import Stripe from 'stripe'
import { env } from '@/lib/env'

const stripe = new Stripe(env.STRIPE_SECRET_KEY)

export async function POST(request: Request) {
  const body = await request.text() // Must be raw text — JSON.parse() breaks the signature
  const signature = request.headers.get('stripe-signature')!

  let event: Stripe.Event
  try {
    event = stripe.webhooks.constructEvent(body, signature, env.STRIPE_WEBHOOK_SECRET)
  } catch {
    return new Response('Invalid signature', { status: 400 })
  }

  switch (event.type) {
    case 'customer.subscription.updated':
      // handle...
      break
  }

  return new Response(null, { status: 200 })
}

Test before every deploy that touches webhook logic:

stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger customer.subscription.updated

Step 10 — Know your rollback plan before you deploy

Before clicking deploy: if this breaks, what's the first step?

On Vercel:

Dashboard → Deployments
Find the last working deployment
Click "..." → "Promote to Production"

This takes 30 seconds. But you need to know where it is before you're in panic mode at midnight.

Warning: Rolling back code doesn't roll back the database. If your deploy included a migration, rolling back the code leaves the new schema in place. This is why every migration must be backward compatible with the previous version of your code.

Step 11 — Smoke test the critical path

After every deploy, manually run through the one flow that would destroy you if it broke:

Sign up or log in
Do the core action (create a project, submit a form, process a payment)
Verify the outcome (data saved, email sent, webhook fired, UI updated)

This takes 2 minutes. Skip it once and you'll spend 2 hours recovering from the deploy you didn't check.

Step 12 — Alert channel that humans actually see

"Errors go to Sentry" is not an alert strategy if nobody checks Sentry.

Sentry error         → Slack #alerts (immediate)
503 health check     → PagerDuty or email (immediate)
Stripe webhook fail  → Slack #payments (immediate)
Daily summary        → Slack #ops (every morning)

The full deploy sequence

1.  Merge PR to main
2.  CI: lint → typecheck → build (validates env vars)
3.  CI: database migrations
4.  Vercel auto-deploys
5.  Smoke test critical path (2 minutes)
6.  Check Sentry for new errors (first 10 minutes)
7.  Feature flag ON → 5% of users
8.  Monitor 30 minutes
9.  Roll out to 100% — or rollback

Automate the checklist

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npm run typecheck
      - run: npm run lint
      - run: npm run build

  migrate:
    needs: check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx drizzle-kit migrate
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

migrate runs after check passes. Vercel deploys after the push — by then, migrations are already applied. Migrations always run first, automatically.

What juniors skip (and why it hurts)

Skip	Consequence
Env validation	`undefined` reads silently, crashes at runtime
Migration order	New code breaks on old schema during deploy window
Feature flags	Real users are your QA team
Health check	Outages discovered by users, not monitors
Rate limiting on auth	Login brute-forced while you sleep
Stripe signature	Anyone can fire fake payment events
Rollback plan	Panic decisions under pressure
Smoke test	Broken flow discovered by your best customer

This checklist is 5 minutes before a deploy that saves 5 hours after one. Seniors run it on every push — even the "it's just a typo fix" ones. Especially those.

Full guide with t3-env setup, Drizzle migrations, and GitHub Actions workflow:
https://stacknotice.com/blog/senior-dev-production-checklist-2026

How Senior Devs Start a Full-Stack Project in 2026

Carlos Oliva Pascual — Tue, 26 May 2026 13:58:50 +0000

Most tutorials show you how to build a to-do app. This guide shows you how a senior developer starts a real project — the decisions before writing a single line of business logic, the tools they pick, and why.

The mindset shift

Juniors ask: "what framework should I use?"

Seniors ask: "what problems am I solving, and what's the minimum complexity that solves them?"

The 2026 stack

Layer	Choice	Why
Framework	Next.js 15 (App Router)	SSR + RSC + API routes in one
Language	TypeScript (strict)	Catches bugs before runtime
Styling	Tailwind CSS v4	Fastest UI iteration
Components	shadcn/ui	Copy-paste, you own the code
Database	PostgreSQL via Neon	Serverless, free tier, branching
ORM	Drizzle	Type-safe, SQL-like, fast
Auth	Clerk	Best DX for most projects
Validation	Zod	Runtime + compile-time safety
Forms	React Hook Form + Zod	Performance + validation
Linting/Format	Biome	ESLint + Prettier in one, 100x faster
Env vars	t3-env	Type-safe env variables
AI assistant	Claude Code	Best for full-stack tasks

Step 1 — Initialize correctly

npx create-next-app@latest my-app \
  --typescript \
  --tailwind \
  --eslint \
  --app \
  --src-dir \
  --import-alias "@/*"

Enable strict TypeScript immediately

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitReturns": true,
    "exactOptionalPropertyTypes": true
  }
}

Enable strict mode before writing any code. Enabling it after 10,000 lines is a nightmare.

noUncheckedIndexedAccess forces you to handle array[0] being potentially undefined. This prevents an entire class of runtime bugs.

Step 2 — Replace ESLint + Prettier with Biome

Biome does what ESLint and Prettier do, in one tool, 100x faster.

npm install --save-dev @biomejs/biome
npx biome init
npm uninstall eslint eslint-config-next
rm .eslintrc.json

biome.json:

{
  "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
  "organizeImports": { "enabled": true },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "error",
        "noUnusedImports": "error"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "es5",
      "semicolons": "asNeeded"
    }
  }
}

Step 3 — Folder structure that scales

src/
├── app/
│   ├── (auth)/            # Route group — auth pages
│   ├── (dashboard)/       # Route group — protected pages
│   └── api/
├── components/
│   ├── ui/                # shadcn/ui components
│   └── [feature]/         # Feature-specific components
├── lib/
│   ├── auth.ts
│   ├── db.ts
│   ├── env.ts
│   └── utils.ts
├── db/
│   ├── schema.ts
│   └── migrations/
├── hooks/
├── types/
└── actions/               # Server Actions

Step 4 — Type-safe environment variables

npm install @t3-oss/env-nextjs zod

// src/lib/env.ts
import { createEnv } from '@t3-oss/env-nextjs'
import { z } from 'zod'

export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    CLERK_SECRET_KEY: z.string().min(1),
    NODE_ENV: z.enum(['development', 'test', 'production']),
  },
  client: {
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
    NEXT_PUBLIC_APP_URL: z.string().url(),
  },
  runtimeEnv: {
    DATABASE_URL: process.env.DATABASE_URL,
    CLERK_SECRET_KEY: process.env.CLERK_SECRET_KEY,
    NODE_ENV: process.env.NODE_ENV,
    NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: process.env.NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY,
    NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL,
  },
})

If a required env var is missing, the build fails — not a silent runtime crash at 3 AM.

Step 5 — Database with Drizzle + Neon

npm install drizzle-orm @neondatabase/serverless @paralleldrive/cuid2
npm install --save-dev drizzle-kit

// src/db/schema.ts
import { pgTable, text, timestamp, boolean } from 'drizzle-orm/pg-core'
import { createId } from '@paralleldrive/cuid2'

export const users = pgTable('users', {
  id: text('id').primaryKey().$defaultFn(() => createId()),
  clerkId: text('clerk_id').unique().notNull(),
  email: text('email').notNull(),
  plan: text('plan').default('free').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().$onUpdate(() => new Date()).notNull(),
  deletedAt: timestamp('deleted_at'), // soft delete — never hard delete users
})

Always use cuid2 for IDs, never auto-increment integers. cuid2 is URL-safe, doesn't expose your record count, and works across distributed systems.

Step 6 — Server Actions for mutations

Forget API routes for simple mutations.

// src/actions/projects.ts
'use server'
import { revalidatePath } from 'next/cache'
import { z } from 'zod'
import { requireAuth } from '@/lib/auth'
import { db } from '@/lib/db'
import { projects } from '@/db/schema'

const schema = z.object({
  name: z.string().min(1).max(50),
  isPublic: z.boolean().default(false),
})

export async function createProject(input: unknown) {
  const user = await requireAuth()
  const parsed = schema.safeParse(input)
  if (!parsed.success) return { error: parsed.error.errors[0]?.message }

  const [project] = await db
    .insert(projects)
    .values({ ...parsed.data, ownerId: user.id })
    .returning()

  revalidatePath('/dashboard')
  return { data: project }
}

Always validate in Server Actions — they're public endpoints anyone can call.

Step 7 — Using Claude Code the right way

npm install -g @anthropic-ai/claude-code
claude

Works great:

"Add a description column to the projects table and generate the migration"
"Write a Server Action that deletes a project, checking the user owns it"
"Add rate limiting to /api/generate using Upstash"

Creates problems:

"Build me a complete project management app" (too vague)
Copying generated code without reading it

Create a CLAUDE.md at the root:

# Project CLAUDE.md

## Conventions
- Use cuid2 for all IDs, never auto-increment
- Soft-delete users (deletedAt), never hard delete
- Server Actions for mutations, not API routes
- Import env from @/lib/env, never process.env
- requireAuth() at the top of every protected action
- Return { data } or { error }, never throw

Claude Code reads this file and follows your conventions automatically.

What seniors skip (and you should too)

No unit tests at the start — your schema changes constantly. Test when stable.
No Redux/Zustand at the start — React state + Server Components handle 90% of cases.
No microservices — start with a monolith, split when you have a real reason.
No Docker in development — run the dev server directly.
No CI/CD on day one — Vercel auto-deploys. Add GitHub Actions when you need custom steps.

Common junior mistakes

Mistake	Fix
`process.env.X` everywhere	t3-env — fails at build time if missing
Auto-increment integer IDs	cuid2 — URL-safe, no sequential exposure
Hard-delete users	`deletedAt` soft-delete
`any` type everywhere	Strict TS — fix errors as you go
Deploy first, migrate after	Migrate first, always

Full guide with Drizzle setup, Clerk auth config, and the complete 30-minute checklist:
https://stacknotice.com/blog/fullstack-project-setup-senior-2026

Zero-Downtime Database Migrations in Production (2026)

Carlos Oliva Pascual — Tue, 26 May 2026 11:28:31 +0000

A DROP COLUMN that takes 2 seconds in development can lock a production table for 4 minutes in production. Here's how senior engineers handle migrations without downtime.

The core problem

Your database and app code deploy independently. During deployment, two versions of your code run simultaneously. If your migration breaks compatibility with the old version, you have an outage.

Rule: every migration must be backward compatible.

drizzle-kit push vs generate+migrate

Never use drizzle-kit push in production — it applies changes directly without migration files.

Always use:

npx drizzle-kit generate
npx drizzle-kit migrate

Safe vs dangerous operations

Safe (no table locks):

ADD COLUMN (nullable)
CREATE TABLE
CREATE INDEX CONCURRENTLY
ADD CONSTRAINT NOT VALID

Dangerous (locks entire table):

DROP COLUMN
RENAME COLUMN
ALTER COLUMN SET NOT NULL
Changing column type

The expand-contract pattern

How to rename a column across 3 phases and 3 separate deploys.

Phase 1 — Add new column:

ALTER TABLE users ADD COLUMN display_name text;

Deploy code that reads display_name, writes to both columns.

Phase 2 — Backfill:

UPDATE users SET display_name = name WHERE display_name IS NULL;

Deploy code that only uses display_name.

Phase 3 — Drop old column:

ALTER TABLE users DROP COLUMN name;

Adding NOT NULL without locking

ALTER TABLE SET NOT NULL blocks all reads and writes. The safe way:

Step 1:

ALTER TABLE users ADD COLUMN display_name text;

Step 2 — Backfill in batches:

UPDATE users SET display_name = name
WHERE id IN (SELECT id FROM users WHERE display_name IS NULL LIMIT 500);

Repeat with 50ms pauses until done.

Step 3:

ALTER TABLE users
ADD CONSTRAINT users_display_name_not_null
CHECK (display_name IS NOT NULL) NOT VALID;

ALTER TABLE users VALIDATE CONSTRAINT users_display_name_not_null;

CREATE INDEX CONCURRENTLY

-- Locks the table — never in production
CREATE INDEX idx_users_email ON users(email);

-- Non-blocking — always use this
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

CI/CD rule

1. Run migrations FIRST
2. Deploy new code AFTER

Never simultaneously. Never deploy first.

Full guide with Drizzle ORM examples: https://stacknotice.com/blog/saas-database-migrations-zero-downtime