Milestone map
Milestone map
3 milestones
Ship a Working Application with Frontend and Backend
6–10 weeks (depending on scope and prior experience)
Build and deploy a working web application that has both a frontend (user interface) and a backend (server-side logic and a real database). The application must solve a real problem — not a tutorial clone — and must be accessible at a public URL. The stack choice is yours: Next.js + Supabase, Express + PostgreSQL, Django + React, or any equivalent combination. Core requirements: user authentication (users can sign up, log in, and see their own data), at least one create-read-update operation on persistent data, and a deployment that is live and accessible without a local development environment.
Proof required
Submit a public GitHub repository (with README explaining setup, dependencies, and how to run locally) and a live URL where the application is running. The README must name the problem the app solves and who it is for.
What gets checked
- Application is deployed and accessible at a public URL without the reviewer needing to run it locally — deployment is not optional
- User data is isolated — one user cannot see another user's data; this must be enforced server-side not just in the UI
- README explains the problem and who it is for — not just the technical stack; a non-technical reader should understand what the app does from the README alone
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Access the live URL and attempt to create an account, log out, create another account, and confirm the second account cannot see the first account's data
- Check the GitHub repository for a README that names the problem — ask the submitter to explain in 2 sentences what real problem the app solves
- Ask the submitter what they would do differently if they built it again — this tests whether the project produced genuine learning about the stack
- Confirm the database persists between sessions: log data, close the browser, reopen — the data should still be there
- Building a tutorial clone (to-do app, blog, chat app) without a real problem statement — a clone demonstrates following instructions, not product thinking
- Deploying a frontend only with a mock backend — the backend must persist data between sessions in a real database
- Server-side data isolation that relies only on a user_id query parameter rather than an authenticated session — this is a security flaw, not an implementation
Add a Feature Under a Real Constraint
3–6 weeks
Add a meaningful feature to your M1 application — or to an existing production codebase — under a real constraint. The constraint must be external: a real user asked for this feature, your team decided it was needed, or there is a real deadline. The feature must touch both the frontend and backend (a database schema change and a new API endpoint, plus a new UI element). You must also write at least 3 automated tests for the new backend code.
Proof required
Submit a pull request link (or a commit comparing before and after if solo) that shows the schema change, the new API endpoint, the frontend UI element, and the 3 automated tests. Include a 100-word description of the constraint (who asked for what and by when).
What gets checked
- Pull request diff shows changes to the database schema, at least one new API endpoint, at least one UI component, and at least 3 tests
- Tests cover at least one unhappy path (what happens when the input is invalid, the user is not authenticated, or the expected data is not there)
- The 100-word constraint description names a real person or team who requested the feature — 'I thought this would be a good idea' is self-imposed, not a real external constraint
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter to name the person or team who requested the feature — a real constraint has a real requester with a real reason
- Run the 3 tests independently and confirm they pass — then remove or comment out the new code and confirm at least 1 test fails
- Ask the submitter what they had to negotiate or cut to meet the constraint — real constraints always involve some trade-off
- Check that at least one test covers an unhappy path — the absence of unhappy-path tests is the most common indicator of untested assumptions
- Adding a purely frontend feature with no backend change — the M2 constraint specifically requires touching both layers
- Tests that only test the happy path (input is valid, user is authenticated, expected data exists) — real-world reliability comes from handling the edge cases
- A constraint that is actually self-imposed — the value of the external constraint is that it forces you to negotiate scope, ask clarifying questions, and deliver to someone else's definition of done
Walk Through Your Codebase in a Technical Interview
1–2 weeks (60–90 min session)
Present your M1 application and the M2 feature to a qualified technical reviewer: a senior software engineer, tech lead, or engineering manager with 5+ years of full-stack development experience. The reviewer reads the codebase before the session and prepares questions about specific implementation choices. During the session, the reviewer asks you to explain an architectural decision, extend the application with a new requirement, and identify a bug or vulnerability they have spotted in the code.
Proof required
Submit the GitHub repository link plus the reviewer's written assessment: the architectural decision they asked about and your explanation, the new requirement they introduced and your approach, the bug or vulnerability they identified and what you would do to fix it, and their sign-off confirming their role and a live session.
What gets checked
- Reviewer identified a real bug or vulnerability — not a code style issue; a real correctness or security problem that exists in the code
- New requirement response includes a specific technical approach (which file, which function, what data change) not a general description
- Reviewer sign-off confirms 5+ years of full-stack experience (not frontend-only or backend-only)
Resources
Foundationstart here
What a verifier looks for
- Read the codebase before the session and identify 1 real bug or vulnerability to introduce as the session's final question — authentication gaps and missing input validation are common
- Ask the architectural decision question early — the submitter's ability to explain why they made a specific choice (not just what it is) is the most revealing indicator of genuine understanding
- The new requirement must require a change to both frontend and backend — a frontend-only requirement is too narrow for a full-stack session
- Reviewer minimum qualification: 5+ years of full-stack development in production; frontend-only or backend-only specialists are less appropriate for a full-stack review
- A reviewer who focuses on code style (naming conventions, formatting) rather than architecture and correctness — the session is about engineering judgment, not style
- New requirement response that is conceptual ('I would add a new table') without naming specific changes to specific files
- Codebase that is a tutorial or AI-generated scaffold rather than code the submitter genuinely understands — the review will reveal this quickly