Ship a Full Stack App From Scratch

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

Common mistakes

• 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

Resources

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

You'll sign in first, then come straight back here.

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

Common mistakes

• 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

Resources

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

You'll sign in first, then come straight back here.

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)

Common mistakes

• 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

Resources

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

You'll sign in first, then come straight back here.