Admin Dashboard UI built with Shadcn and Next.js.
Book Heaven is a web application created to make a real workflow clearer, faster, and easier to trust. It turns a focused product idea into something people can use, evaluate, and understand without needing to inspect the source code.
Why Book Heaven exists
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.
The goal is not simply to add another tool. Book Heaven is designed to reduce the friction around that problem and give people a more dependable way to complete the work.
What it delivers
- 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.
The experience
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.
The project brings the important parts of the workflow into one coherent experience. Its interface and behavior are shaped around the people using it, while the implementation stays focused on predictable results and honest feedback.
What to know
Every product has boundaries. These are the most important considerations for Book Heaven:
- 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.
- The Stripe dependency used a caret range, allowing a newer release whose TypeScript contract expected a later API version than the application intentionally used.
- Environment-backed providers initialize during route collection, so local checks had to distinguish absent production credentials from the build failures under investigation.
- Acceptance required the exact script URL and data attributes to appear in public production HTML after a successful main-branch deployment.
These limitations are presented openly so visitors can understand where the project works well, what it depends on, and what may change in future versions.
Current status
Resolved and deployed. The current release demonstrates the core value of the project and the main end-to-end experience.
My role was incident diagnosis, build engineering, and release verification, covering next.js build reliability, dependency compatibility, and vercel delivery. The related case study explains the decisions and delivery process in greater depth for visitors who want the engineering story behind the product.