Skip to main content
One checkpoint at a time

Build Taskboard from the first request to the final check

Start in an empty taskboard folder. Keep one project throughout these fifty steps. Let AI implement each bounded change. Review the code and run the checkpoint checks before advancing.

Build completion is your record of observed results. The course does not run checks against your local project.

1. Build a task API​

Create and list tasks in a local browser.

  1. Start the server in an empty folder.
  2. Create the first task.
  3. List tasks with a clear HTTP contract.
  4. Keep requests responsive while awaiting work.
  5. Put request checks in the right order.
  6. Reject invalid task input.

Release check. Create a task through the form, list it, reject bad input, and explain why a restart loses it.

2. Keep tasks in PostgreSQL​

Tasks survive a restart and conflicting edits are rejected.

  1. Give tasks a relational home.
  2. Apply the first migration safely.
  3. Replace the in-memory task store.
  4. Reject impossible relationships.
  5. Describe the persisted model in code.
  6. Commit a change and its history together.
  7. Protect task edits from stale versions.
  8. Load bounded task pages.

Release check. Create, edit, paginate, restart, and reload a task. Prove a stale edit and invalid relationship fail.

3. Add accounts and teams​

Signed-in users work only inside their authorized workspace.

  1. Register an account safely.
  2. Keep the caller signed in.
  3. Protect browser writes.
  4. Create a team workspace.
  5. Scope every task to its workspace.
  6. Enforce each team role.
  7. Prove that changed IDs grant no access.

Release check. Register, log in, choose a workspace, add a project and comment, then reject a foreign account and forbidden role.

4. Deliver durable work​

The worker delivers email and the app survives retries.

  1. Expose the gap after a commit.
  2. Record the work before returning success.
  3. Run the first worker.
  4. Recover a stopped worker.
  5. Retry recorded failures without a tight loop.
  6. Deliver an email through local SMTP.
  7. Verify the account through its email link.
  8. Invite a verified colleague.
  9. Reset the password and revoke sessions.
  10. Replay a create without adding another task.
  11. Reject a changed payload under the same key.
  12. Inspect and replay failed work deliberately.
  13. Check what an external acknowledgement proves.

Release check. Verify an account, invite and accept a colleague, reset a password, replay a task create, and recover an expired job claim.

5. Add live updates and payments​

Connected teammates refresh changes and billing follows provider state.

  1. Connect the second browser.
  2. Recheck access before sending an event.
  3. Recover the view after a disconnect.
  4. Create a test checkout safely.
  5. Enforce the subscription on the server.
  6. Verify the provider message before trusting it.
  7. Record each provider event once.
  8. Reconcile with current provider state.

Release check. Use two clients, disconnect and reconnect, exercise test checkout and portal, and reject invalid or duplicate webhooks.

6. Run and recover the project​

The complete app starts, stops, restores, and passes its checks.

  1. Finish the security boundaries.
  2. Follow a failure across API and worker.
  3. Find and remove one measured bottleneck.
  4. Package the whole app stack.
  5. Rehearse a deployment locally.
  6. Drain work when a process stops.
  7. Restore into a fresh database.
  8. Accept the completed Taskboard project.

Release check. Start API and worker from built images, rehearse migrations, drain shutdown, restore into a disposable database, and run final acceptance.

The deployment step rehearses locally. Finish shutdown, restore, and final acceptance before a public rollout. The completed reference app is a comparison when you need one, not code to preload into the empty project.