First App Shipped (Curriculum Complete + Public Repo)

Proof required

Submit: a GitHub repository (public or shared) containing your program's source code and a README with installation instructions and example output; a screenshot or video of the program running; and a completion certificate or progress screenshot from the curriculum you chose. The README must allow a stranger to run the program without asking you questions.

What gets checked

• Program runs on a clean machine following the README — if the README requires asking the submitter for clarification, it is incomplete
• Program does something genuinely useful or interesting to the submitter — 'hello world' or a tutorial exercise submitted verbatim does not count
• Curriculum completion evidence is real: a certificate, a progress page showing ≥80% completion, or a screenshot of a final project grade — a self-report of 'I finished it' is not sufficient

Common mistakes

• Choosing a language or curriculum and abandoning it when it gets hard — the M1 proof requires following one structured path through, not hopping between tutorials
• Building a program that only runs in the development environment because of hardcoded paths or untracked dependencies
• Submitting tutorial exercise code as the 'program' — the program must be something the submitter conceived, not an exercise from the curriculum

Resources

What a verifier looks for

• Run the program from the README on a clean machine — if it fails or requires clarification, note that specifically in the review
• Ask the submitter to explain what a specific function in their code does — a confident explanation in their own words confirms authorship
• Ask what the hardest part of the program was to build — vague answers suggest the submitter did not write it themselves
• Ask what the curriculum's final project was and why they chose their own program topic — there should be a clear personal motivation

Proof required

Submit: the GitHub repository with source code and README; evidence of the real user (a message, a screenshot of them using it, or their written feedback); and your 200-word reflection naming what you cut from the original plan and one thing you would do differently now.

What gets checked

• Real user evidence is specific: a message, screenshot, or feedback note from a named person — 'my friend used it' without evidence does not count
• Program handles more than one type of input or user scenario — a script with a single hardcoded input path is not a project
• 200-word reflection names something you cut and explains why — a reflection that only describes what was built has not addressed the prompt

Common mistakes

• Building for a hypothetical user rather than a real one — the user evidence requirement exists precisely to force real deployment
• Scoping the project so large it never ships — a working small program delivered to a real user is worth more than an unfinished ambitious one
• Treating the 200-word reflection as a description of the program rather than an honest account of what was cut, what broke, and what was learned

Resources

What a verifier looks for

• Ask the submitter to describe the real user's reaction — what did they find useful and what confused them?
• Ask what the original plan included that was cut — the absence of any cuts suggests the project was scoped after the fact
• Run the program using the README — if it requires the submitter's help to run, the README is insufficient
• Ask what they would build differently if they started over — a specific answer shows genuine learning; 'nothing' suggests the reflection was superficial

Proof required

Submit a session record containing: the reviewer's name and a verifiable credential showing 3+ years of professional programming experience (LinkedIn or GitHub profile URL); a summary of at least two specific design questions they raised; and a 200-word reflection on the most important thing the review changed about how you think about code.

What gets checked

• Reviewer credential is verifiable and shows professional programming experience of 3+ years — a senior student or hobby coder is not sufficient
• Two specific design questions are documented: not 'they asked good questions' but the actual question and your answer
• 200-word reflection names a specific change in thinking — not just 'I learned a lot' but a concrete shift in how you approach a specific problem

Common mistakes

• Choosing a reviewer who is a fellow learner or peer — the session needs someone who can recognise poor design choices you are not yet aware of
• Preparing a scripted demo rather than a live walkthrough — the reviewer must be able to ask about any part of the code, not just the parts you rehearsed
• Treating the post-session reflection as a summary of what you did rather than what the review changed — if it was a real review, something changed

Resources

What a verifier looks for

• Confirm the reviewer credential is current and shows real professional experience — check that the LinkedIn or GitHub profile is active and shows a programming role, not just a claimed title
• Ask the submitter to repeat one of the reviewer's specific questions from memory — if they cannot, the session details were likely reconstructed after the fact
• Ask what the reviewer said about the biggest design weakness — every experienced reviewer identifies something; 'they said it was good' without a critique is a red flag
• Ask what they changed about the code or their thinking after the session — some change, however small, is expected from a real review