Home Projects

You do not finish a track.
You ship it.

Every track on the platform is a sequence of project milestones. Each one has a brief, a deliverable and a review — so what you carry away is work you can show, not a completion percentage.

01/The loop

Step 01

The brief

Each milestone opens with a written brief: what you are building, what counts as finished, and the questions the review will ask. No brief says "watch this and take notes" — every one names something you hand in.

Step 02

The build

You build it with the tools the track names, on your own machine, in your own repository. Where the work needs data, the track points at a dataset you are allowed to use rather than one you have to buy.

Step 03

The submission

You submit the artefact plus a short note: what it does, how to run it, what you would do differently and what you are unsure about. The note matters as much as the code — it is where the reasoning shows.

Step 04

The review

A reviewer works through the brief line by line and answers it in writing: met, partly met, or not met, with the specific reason. A milestone is only marked verified when the deliverable does what the brief asked.

What a review actually checks

A review is not a grade out of ten and it is not a rubber stamp. It works through the same five questions every time, and it answers them in writing.

  • Does it run from a clean checkout with the instructions you supplied?
  • Does it do what the brief asked — not something adjacent that was easier?
  • Are the failure modes handled, or hidden? Empty input, wrong input, no network, no data.
  • Is the reasoning written down, including the decision you were least sure about?
  • Could a different person pick this up and continue it next week?

The weekly rhythm

Week 1 of a blockRead the brief, plan the smallest thing that satisfies it, and set up the repository.
Weeks 2–3Build. Ask questions in the open; the questions and answers become part of the track notes.
End of the blockSubmit the artefact and the note, then revise against the review before moving on.
After the reviewThe milestone is recorded as verified, and the track moves to the next one.

Where the milestones come from

The milestones were written backwards from the work: what a junior developer, analyst or research associate is asked to do in their first months, broken into blocks of a few weeks that each end in something checkable. Where a milestone depends on software that changes quickly, the brief names the concept and the tool separately, so a version bump does not invalidate your work.

Pick a track and take the first milestone.

Applications are open — a person reviews yours, a letter of offer follows, and the first milestone brief is waiting inside the track.