Skip to content

Book Heaven

websiteLast commit

Recovering a failed Vercel rollout by separating a correct feature change from build-system failures, hardening the production build, and verifying the deployed widget contract end to end.

Role
Incident diagnosis, build engineering, and release verification
Scope
Next.js build reliability, dependency compatibility, and Vercel delivery
Status
Resolved and deployed
Book Heaven public application after the Vercel deployment recovery

Problem

The SupportKori integration was correct in source and merged to main, but Book Heaven's Vercel production deployment failed before the new build reached visitors. The live site therefore looked as if the widget change were missing, even though the actual fault was in the delivery path. The recovery needed to identify each build blocker without weakening existing API contracts or treating a merged pull request as proof of a successful release.

Constraints

  1. C1

    The large Next.js application compiles many routes and integrations inside Vercel's finite build-memory envelope; the default Node.js heap was exhausted during production validation.

  2. C2

    The Stripe dependency used a caret range, allowing a newer release whose TypeScript contract expected a later API version than the application intentionally used.

  3. C3

    Environment-backed providers initialize during route collection, so local checks had to distinguish absent production credentials from the build failures under investigation.

  4. C4

    Acceptance required the exact script URL and data attributes to appear in public production HTML after a successful main-branch deployment.

Architecture

A four-stage recovery loop separated source correctness, deterministic production compilation, platform deployment, and public runtime verification so each failure could be diagnosed at the boundary where it occurred.

01

Source contract

A root-layout Next.js Script component owns the exact SupportKori URL, account ID, message, color, and position.

02

Build envelope

Prisma generation and Next.js compilation run with a 4 GB Node.js heap and two build workers to keep resource use predictable.

03

Dependency contract

Stripe is pinned to version 20.1.0 so its types remain aligned with the API version selected by the application.

04

Release proof

GitHub status, the Vercel preview, the production deployment, and the returned public HTML form a chain of release evidence.

Decisions

D1

Separate feature correctness from delivery health

The widget implementation and the deployment pipeline were tested independently, preventing a stale production page from being misdiagnosed as a frontend defect.

D2

Make the build resource budget explicit

Increasing the Node.js heap and limiting parallel workers addressed the resource failure deterministically instead of relying on repeated deployment attempts.

D3

Pin the dependency to the application's API contract

Stripe stayed on the compatible 20.1.0 release rather than silently changing the application's API version to satisfy types from an unintended upgrade.

D4

Verify the artifact visitors receive

The incident was considered resolved only after Vercel reported a successful main deployment and the public response contained every required widget attribute.

Contribution

  • Confirmed that the merged root-layout integration was correct while the public site was still serving the previous deployment.
  • Reproduced the production build and traced the failure through memory pressure and Stripe type-version drift.
  • Updated all production build paths with a 4 GB heap, limited Next.js to two build workers, and pinned Stripe to the compatible release.
  • Delivered the fixes through reviewed pull requests, then checked the Vercel preview, production status, and live HTML contract.

Outcomes

  • The repaired main-branch build completed successfully on Vercel at the verified commit.
  • Book Heaven's public site now loads the exact SupportKori script with the required ID, message, color, and position.
  • Build behavior is less sensitive to heap exhaustion and excessive worker parallelism.
  • Stripe type compatibility can no longer drift beyond the selected API contract through an implicit minor-version update.
  • The release workflow now distinguishes code merged from deployment completed and production artifact verified.

Product screenshot

Book Heaven public application after the Vercel deployment recovery
The live Book Heaven beta was the final verification target: the fix was complete only when production served the intended widget contract.

Verified stack

  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Prisma
  • Redis
  • BullMQ
  • Socket.io
  • Stripe
  • REST APIs
  • Tailwind CSS
  • shadcn/ui
  • Radix UI
  • TanStack Query
  • React Hook Form
  • Resend
  • Zod
  • System Design

Working through something similar?

Share your challenge, scope, and timeline to start a focused conversation.