LifeQuest

Promotional Thumbnail
Landing Page

Inspiration

Large goals often fail for a simple reason: the next action is unclear, progress feels invisible, and motivation disappears before meaningful results appear.

Most productivity applications present users with another list of tasks. I wanted to explore a different approach: what if completing a real goal felt like progressing through an adventure?

LifeQuest transforms practical goals into focused role-playing campaigns. The fantasy layer is not a distraction from the work—it gives the work context, momentum, visible stakes, and a sense of progression.

What it does

LifeQuest allows a user to describe:

A real-world goal
The time they can commit each day
Their biggest obstacle
Their preferred difficulty

GPT-5.6 converts these constraints into a structured campaign containing:

A hero identity
A themed realm
A nemesis representing the user's obstacle
A practical sequence of quests
Visible success requirements
XP rewards and enemy damage

Users open a quest, complete the real-world task, and submit private image or screenshot proof.

On the live path, proof is processed on the server. The image is validated and moderated before GPT-5.6 assesses it against every success requirement. The result includes a clear requirement-by-requirement explanation rather than only a vague accepted or rejected verdict.

When proof is accepted, the user earns XP, damages the campaign enemy, unlocks progression, and moves closer to completing the campaign.

The browser never decides its own reward. XP and enemy damage are applied through a server-authoritative, idempotent PostgreSQL function so repeated requests cannot award progress twice.

How we built it

LifeQuest is built as a single Next.js App Router application using:

Next.js and React
Strict TypeScript
Tailwind CSS
Supabase Authentication
Supabase PostgreSQL
Row Level Security
Private Supabase Storage
OpenAI Responses API
GPT-5.6 Structured Outputs
OpenAI image understanding and moderation
OpenAI Realtime for narration
Zod validation
Vitest and Testing Library
Playwright browser testing
Vercel for deployment

Campaign generation uses a schema-validated GPT-5.6 response. Generated quests are checked for ordering, practical duration, reward limits, difficulty, and complete success requirements before they are saved.

Campaign and quest creation is atomic, preventing partially created campaigns.

Proof files remain private and are stored in user-scoped paths. File size, MIME type, binary signature, ownership, and quest status are checked before verification.

Supabase Row Level Security restricts users to their own profiles, campaigns, quests, and submissions.

How Codex helped

Codex was used throughout the core development workflow rather than only for isolated code suggestions.

It helped inspect and recover the initial incomplete project, complete the Next.js route structure, diagnose strict TypeScript failures, implement reusable interface states, strengthen Supabase security, and build automated tests around the most sensitive application boundaries.

Codex also helped with:

App Router pages and route handlers
Zod schemas and AI response contracts
Atomic and idempotent database functions
Private proof-validation logic
Authentication and authorization boundaries
Responsive layouts down to 320px
Keyboard and reduced-motion accessibility
Unit and browser testing
Production-hardening checks
Deployment and handoff documentation

I remained responsible for the key product and engineering decisions: limiting the MVP to one focused progression loop, keeping proof private, preventing the browser from awarding rewards, using an honest deterministic presentation fallback, and avoiding unrelated social, marketplace, and payment features.

How GPT-5.6 is used

GPT-5.6 has two meaningful runtime responsibilities.

First, it transforms a user's practical goal and constraints into a bounded, structured RPG campaign. The output is validated before it can enter the database.

Second, it assesses private proof against every visible quest requirement. It returns a structured verdict with a separate assessment for each requirement.

The model is treated as an untrusted external boundary. Its outputs are schema-validated, low-confidence or incomplete assessments are rejected, and progression is applied only after server-side verification succeeds.

Challenges we faced

Making AI progression trustworthy

The most important challenge was preventing a user or browser request from directly claiming success, XP, or enemy damage.

We solved this by moving progression into a service-role-only PostgreSQL function with row locking and idempotency protection.

Protecting private proof

Proof images may contain private information, so files must not be publicly accessible.

LifeQuest uses a private storage bucket, user-scoped paths, server-side ownership validation, file-signature checks, moderation, and privacy-safe verification receipts.

Keeping generated quests practical

A creative campaign is not useful if its quests are vague or impossible.

The application validates generated quest order, daily-time constraints, reward ranges, success requirements, and difficulty before persistence.

Building a reliable presentation

Live AI and external services can fail during a short demonstration. LifeQuest therefore includes an explicitly labelled seeded demo with deterministic accepted and rejected proof examples.

The seeded mode is never presented as live AI. It exists so judges can reliably experience the complete interaction and progression loop, while the repository contains the separate live OpenAI and Supabase path.

Accomplishments that we're proud of

A complete goal-to-campaign-to-proof progression loop
Structured GPT-5.6 campaign generation
Explainable proof assessment
Private proof storage
Server-authoritative rewards
Duplicate-safe XP and enemy damage
Supabase Row Level Security
A responsive fantasy interface
Keyboard and reduced-motion accessibility
Automated unit, security-contract, and browser tests
A reliable and honestly labelled seeded demonstration
Clear separation between simulated presentation behavior and live AI behavior

What we learned

AI applications need more than a prompt and a model call.

Reliable AI products require validation, authorization, failure handling, privacy controls, idempotency, testing, and honest communication about which results are live and which are simulated.

Structured Outputs made it possible to treat GPT-5.6 as a controlled application component rather than an unrestricted text generator.

Codex was most useful when it worked across the whole repository: understanding architecture, tracing failures across boundaries, implementing focused changes, running tests, and documenting remaining limitations.