Projects Checkpoint

Your Own Project, End to End

Reasoning Checkpoint

A design challenge, worked through in writing — no auto-grading, just a real attempt.

1–2 weeks of evenings

The Challenge

Now it's your turn. Build your own small project end to end, the way Anna did on Hack Day. Pick something you'd actually use: a reading list, a habit tracker, a recipe box, a five-a-side football team organiser, a book-swap list for your street — or your own version of the event waitlist.

Use JavaScript and Node.js like the course, or any language you prefer — the steps are the same. Give yourself a week of evenings rather than two days. Use the checklist below to check your own work honestly as you go.

Your Project Checklist

  • Warm-up: build a small command-line tool first (a calculator, a file organiser, or your own idea) with input validation, a helpful error and a non-zero exit code on failure.
  • Write your requirements on one note and design your resources, tables and endpoints on paper before coding.
  • Build a REST API with a database and full CRUD, with at least one rule enforced by the database (such as a unique constraint) and parameterised queries throughout.
  • Add authentication with hashed passwords, and a server-side authorization check so users can only change their own data.
  • Use Git from the first minute (.gitignore before the first commit, small clear commits, a branch per feature) and write unit and integration tests that run in CI.
  • Containerise it, deploy it with a managed database, a real domain or platform URL, and working HTTPS; keep secrets in the platform's settings.
  • Add structured logs with request IDs, error tracking or clear error logging, and an external uptime check on a /health endpoint.
  • Write a README that someone else can follow on a fresh clone, publish the repository after checking its whole history for secrets, and tag a v1.0.0 release.
Stuck? A Few Hints
  • Smaller is better: two resources and five or six endpoints are plenty for a first project.
  • Ship a working version first, then improve it — don't polish step two before step six works.
  • When you get stuck, use Act 24's order: the error message, the official docs, then search — and keep notes.

Before You Move On

Your first project won't be perfect, and it doesn't need to be. What matters is that it's finished, live, documented and yours. Build it, ship it, then improve it — and then build the next one a little bigger.

Next