From Questionnaire to Recoverable Progress: My Pilates Health Quiz Development Retrospective

Recently, I worked on a small Pilates Health Quiz project. The core goal was to let users fill in health information through a step-by-step questionnaire, save progress on the backend, and eventually generate a basic health assessment result. The project looks like a simple form at first, but the real implementation involved a lot of product and engineering details: step-by-step saving, progress recovery, backend validation, session recognition, and state restoration after users leave halfway through.

Project Background

The core workflow is straightforward: users fill in information such as gender, goals, age, height, current weight, target weight, and exercise frequency. After each step, the frontend syncs the current answer to the backend. If the user closes the page and later returns, the system should automatically restore the previous answers and current progress.

The main stack includes:

• Next.js 16
• React 19
• Prisma
• PostgreSQL / Supabase
• Zod
• Vitest

Step-by-Step Saving: Not Waiting Until the End

It is tempting to build a questionnaire as a single final submission, but this project required saving every step. The benefit is simple: users do not lose their progress if they leave midway.

Whenever a user selects an answer or submits a numeric input, the frontend calls the save logic:

PATCH /api/sessions/:sessionId/answers

The request body only sends incremental data for the current step:

{
  currentStep: nextStep,
  answers: [
    {
      stepKey: question.key,
      questionKey: question.key,
      value
    }
  ]
}

The backend uses Prisma upsert to save answers. That means when a user changes the same question, the system updates the existing answer instead of creating duplicate records.

Progress Recovery: From localStorage to Cookie Session

At first, the project stored a randomly generated sessionId in frontend localStorage. This worked, but it had an obvious limitation: session identification depended entirely on frontend-readable data, which does not feel like a real backend session.

I later upgraded this to an HttpOnly cookie session.

The current flow is:

1. When a user answers for the first time, the frontend requests POST /api/sessions
2. The backend creates a user and assessment record
3. The backend writes an HttpOnly cookie: pilates_health_quiz_session
4. When the user reopens the page, the frontend requests:

GET /api/sessions/current

The backend reads the sessionId from the cookie and returns that user's assessment progress and saved answers.

With this approach, the frontend no longer needs to read or write a local random ID. Session recognition is handled by the backend, which is much closer to the login/session model used in real products.

A Practical Pitfall: 409 Save Conflict

During development, I ran into a typical issue: when users returned to an earlier question and changed their answer, the backend returned 409 Conflict, and the frontend displayed "Unable to save your answer."

The reason was backend progress validation. The backend did not allow currentStep to move backward. But when a user edits an earlier question, the currentStep sent by the frontend can be lower than the furthest progress already recorded by the backend.

The fix was to separate the "current UI step" from the "furthest step known by the backend":

• The UI can freely go back to earlier questions for editing
• When saving to the backend, currentStep is never lower than the backend's known highest progress

This keeps the backend's anti-skip-step validation while still allowing users to edit previous answers.

Backend Validation Matters Too

This project does not rely only on frontend input restrictions. The backend also uses Zod and custom validation to ensure answers are valid, for example:

• Height must be between 100-250 cm
• Weight must be between 30-300 kg
• Age must be between 13-100
• Question keys must match known steps
• Required prerequisite steps cannot be skipped

This prevents users from bypassing the frontend and submitting invalid data directly through the API.

Test Coverage

I also added tests for the core API flows, including:

• Creating a session
• Saving answers step by step
• Blocking skipped-step submissions
• Blocking invalid answers
• Restricting access to unpaid results
• Unlocking full results after payment
• Restoring current progress through cookie session

The cookie session test verifies that Set-Cookie exists, then uses that cookie to request /api/sessions/current and confirms that the backend can restore the correct session and answers.

Current Completion Status

At this point, the project has the core skeleton of a health assessment product:

• Step-by-step questionnaire flow
• Incremental saving at each step
• Backend persistence
• Cookie session progress recovery
• Backend field validation
• Simulated payment unlock flow
• API test coverage

One clear next step would be upgrading the current guest cookie session into a real account system, such as email login, OAuth login, or binding the cookie session to a user account. That would allow users to recover progress even after switching devices.

Summary

This project reminded me that a seemingly simple questionnaire becomes much more interesting when it needs to behave like a usable product. The core challenge is not just rendering a form; it is deciding how state is saved, restored, validated, and protected across abnormal paths.

Moving from a local random ID to an HttpOnly cookie session made the application feel much closer to a real online product. It is not just "able to save progress" anymore. It now has the beginning of real user session capability.