Ultimate Death Clock

A fictional mortality experience that turns personal quirks into a countdown, a unique incident dossier, and a narrated six-scene reconstruction.

Comment 1

Inspiration

Ultimate Death Clock began with a simple question: what if confronting mortality could be made darkly entertaining, highly shareable, and unexpectedly reflective?

Most online death clocks stop at a date or a generic result. I wanted to build a complete consumer experience around the moment after the estimate: suspense, humour, a coherent fictional incident, an evidence-style dossier, and enough personal detail that the result feels made for one person rather than copied from a template.

The product is explicitly framed as fictional entertainment or non-medical reflection. It is not a diagnosis, medical forecast, or real prediction.

What it does

Ultimate Death Clock offers two experiences:

  • Entertainment mode generates a fictional predicted date, one canonical age, a live countdown, a public result page, and an absurd personalised ending.
  • Reflection mode provides a calmer, clearly non-medical look at everyday lifestyle inputs such as sleep, stress, movement, smoking, and social connection.

The entertainment experience can expand into a Final Chapter Dossier containing:

  • a complete seven-chapter personalised story;
  • a fictional Ultimate Death Certificate;
  • a fictional breaking-news report;
  • three witness statements;
  • predicted final words;
  • an avoidability rating;
  • The Moment You Could Have Survived alternate timeline;
  • a narrated six-scene visual reconstruction based on the same incident facts.

The central design rule is canonical consistency: the teaser, full story, certificate, witnesses, news report, survival decision, scene images, captions, and narration must all describe the same fictional incident.

How GPT-5.6 is used

GPT-5.6 is the primary narrative engine. It receives structured profile inputs and produces a constrained incident model rather than an unconstrained block of prose.

The generation pipeline first creates a canonical IncidentManifest containing:

  • subject facts, date, age, time, and location;
  • setting and incident category;
  • initiating event and cause chain;
  • key props and witness roles;
  • final words and official response;
  • public aftermath;
  • certificate cause and contributing factor;
  • avoidability rating;
  • survival decision and additional years;
  • six reconstruction scenes and six narration beats.

Every dossier artefact is then derived from that same manifest.

The application uses structured output and local validation to enforce:

  • coherent facts across every artefact;
  • non-graphic fictional framing;
  • Australian English;
  • required story depth and section structure;
  • distinct witness voices;
  • a specific survival decision;
  • one consistent integer age everywhere;
  • bounded retries when a result is invalid or too similar to recent generations.

The originality layer compares new results with recent predictions across setting, mechanism, cause chain, props, witness pattern, headlines, chapter structure, survival decision, and repeated phrases. Known fallback-template signatures are rejected rather than served as a successful result.

Personalised media pipeline

The reconstruction is not generated independently from the story.

For each prediction, the application:

  1. derives six portrait image prompts from the stored IncidentManifest;
  2. generates and caches six 1024×1536 scene images server-side;
  3. generates six matching male narration tracks server-side;
  4. creates an original ambient sound bed;
  5. renders the same ordered sequence in the page preview and downloadable WebM;
  6. mixes narration and ambient audio into the browser-generated video export;
  7. protects premium media behind entitlement or short-lived judge-preview access.

Refreshes reuse cached media rather than regenerating assets and incurring repeated cost.

How Codex accelerated the build

Codex was used throughout the project as an implementation, debugging, and production-recovery partner inside the live Next.js codebase. It accelerated work that would otherwise have taken substantially longer, including:

  • auditing and mapping an existing multi-route application;
  • tracing generation across API routes, database records, server-rendered pages, and client media composition;
  • repairing production deployment and PM2 startup behaviour;
  • implementing the canonical IncidentManifest architecture;
  • adding structured GPT-5.6 generation, validation, originality checks, and bounded retries;
  • removing the repeated deterministic paid-story fallback;
  • enforcing one canonical age and incident across the dossier;
  • implementing the six-scene image, narration, ambient-audio, caching, and protected-media pipeline;
  • hardening judge-preview access without exposing the judge key in public links;
  • preserving Stripe configuration and existing unlock behaviour;
  • refining the homepage and dossier presentation;
  • generating multiple fresh test results and comparing their mechanisms, settings, props, final words, and survival decisions;
  • running production builds, PM2 restarts, HTTP checks, access-control tests, and regression verification.

Codex was especially valuable because this was not a greenfield prompt demo. It had to understand the current implementation, preserve working product infrastructure, make targeted changes, and verify the result on a live deployment.

Product and technical architecture

The application is built with:

  • Next.js 14 and React;
  • TypeScript;
  • Tailwind CSS;
  • Prisma and PostgreSQL;
  • OpenAI GPT-5.6 for structured incident and dossier generation;
  • OpenAI image generation for portrait reconstruction scenes;
  • OpenAI text-to-speech for produced narration;
  • Canvas and MediaRecorder for portrait WebM composition and audio mixing;
  • Stripe pathways for one-time dossier entitlement;
  • Nginx and PM2 for production deployment.

Core product components include:

  • a structured questionnaire and dual-mode result flow;
  • persisted predictions and Final Chapter data;
  • public result pages and branded share previews;
  • share-based short-result unlocking;
  • one-time dossier entitlement and payment pathways;
  • secure judge preview using a protected query key and scoped media token;
  • downloadable certificate and reconstruction assets;
  • a dedicated embeddable widget page.

Challenges

Making every result genuinely distinct

The largest creative challenge was avoiding stories that merely changed a few nouns while retaining the same structure. The solution was to generate the structured incident first, compare it with recent incidents, reject prohibited signatures, and return a retryable error rather than presenting recycled prose.

Keeping every artefact consistent

A story can be entertaining while still contradicting its certificate, witnesses, or reconstruction. Treating the incident as structured data first allows every downstream output to inherit the same facts.

Producing media without breaking entitlement boundaries

Generated scene images and narration require separate browser requests after the result page loads. Judge preview therefore uses a short-lived, prediction-scoped signed media token so the real judge key is never embedded in media URLs or copied into public share links.

Balancing humour and safety

The subject is death, so the experience must remain playful without becoming graphic, cruel, or misleading. The application uses prominent fictional-entertainment framing and separates the humorous experience from the calmer non-medical reflection mode.

What I learned

The strongest lesson was that the result itself is only the beginning. For a product like this, the payoff comes from coherence, pacing, visual presentation, and emotional reward.

I also learned that generative applications need deterministic product controls around the model: schemas, validation, retries, similarity checks, persisted results, entitlement boundaries, media caching, and secure testing access. GPT-5.6 provides the creative intelligence; the application enforces the experience.

Current status

The project is deployed and working at the live URL. Production verification includes:

  • five fresh, structurally distinct entertainment results;
  • consistent age and incident facts across new dossiers;
  • six generated portrait scenes and six narration beats per completed reconstruction;
  • cached media reuse;
  • protected-media access checks;
  • public-result locking and judge-preview unlocking;
  • judge-key removal from share links;
  • successful production build, PM2 restart, and live HTTP checks.

The remaining submission deliverables are the public demonstration video and repository review package.

Built With

Share this project:

Updates