First Three Projects Shipped (Beginner to Public App)

Proof required

Share a screenshot of your terminal showing both programs running with real input and output — not a code editor, the actual terminal. Write 100 words on what you think is happening when Python executes your code line by line. Use your own words — not a definition from a tutorial.

What gets checked

• Terminal shows actual program execution with real input typed by the user, not a code snippet or IDE preview
• The 100-word explanation is in the submitter's own words and shows they traced the execution mentally, even if imperfectly
• Both programs run without errors — the age/birth-year calculation is correct

Common mistakes

• Installing an IDE before writing a single line of code — open the terminal first, IDE later
• Copying the program from a tutorial without typing it yourself — muscle memory is how syntax becomes automatic

Resources

What a verifier looks for

• Terminal screenshot must show the program running with real user input — not a code snippet or IDE preview; reject if no visible input
• Ask the submitter to read their 100-word explanation aloud — if they can explain what input() does and why print() needs the result, the milestone is real
• If the explanation is vague, ask them to modify the program to handle a user who types their age as a word instead of a number — their response reveals whether they understand or just copied

Proof required

Share the code for all three programs (GitHub Gist, Replit, or pastebin — publicly accessible link). Run each program in your terminal and share a screenshot of the output. Write 150 words on which data structure you found most confusing and why, and what you now understand about it that you didn't before.

What gets checked

• All three programs are the submitter's own problems — not the three examples listed in the description verbatim, and not tutorial exercises
• Each program uses a loop and a conditional — verified in the code, not just the submitter's claim
• The confusion reflection names a specific thing (e.g. 'I didn't understand why dictionaries use keys instead of positions') not just 'it was confusing at first'

Common mistakes

• Using the exact problems listed in the description — the point is to choose your own, which forces you to think about what a data structure is actually for
• Writing three separate programs that are essentially the same problem with different variable names

Resources

What a verifier looks for

• Read the code, not just the output screenshots — check that the loop actually iterates over the data structure, not a while True loop that happens to touch a list
• Verify that all three programs solve distinct problems — not the same problem with different variable names, and not the three examples listed in the description verbatim
• Ask: 'Why did you use a dictionary instead of a list for this program?' — if they can answer that, they understand the difference; if they say 'the tutorial used a dictionary,' the understanding isn't there yet

Proof required

Share the refactored program code (public link). Share a screenshot showing the program handling at least three types of bad input gracefully — not crashing, giving the user a useful message. Write 150 words on what you learned about your own program by trying to break it — what assumptions had you made without realising?

What gets checked

• Each function does exactly one thing — a function called get_user_input() that also validates AND processes input is doing three things, not one
• Error handling uses try/except correctly — not just if/else checks that miss edge cases
• The 'assumptions I made' reflection names specific assumptions (e.g. 'I assumed the user would always type a number') not just 'I learned to handle errors'

Common mistakes

• Writing functions that are just renamed blocks of code — a function that does everything the original program did is not a function, it's a renamed main()
• Catching all exceptions with a bare except: clause — this hides real errors and is considered bad practice; catch specific exceptions (ValueError, TypeError) instead

Resources

What a verifier looks for

• Run the submitted program yourself — type a letter where a number is expected, press enter with empty input, type an extremely long string; if it crashes, the error handling is incomplete
• Read the functions — each must do exactly one thing; a function called get_user_input() that also validates AND processes input is doing three things, not one
• Ask the submitter to explain one specific function's single responsibility — if they struggle to name it, the refactoring didn't achieve separation of concerns

Proof required

Share your GitHub repository (not a Gist — a real repo with a README). The README must explain what the program does, how to run it, and why you built it. Record a 2-minute screen recording of yourself running the program and narrating what it does. Write 200 words on the hardest problem you hit and how you solved it — be specific about what you tried that didn't work before you found what did.

What gets checked

• The program solves a problem the submitter named before building — the README 'why I built this' is specific and personal, not 'to practise Python'
• The repository has a real commit history — at least 5 commits showing the program built incrementally, not one commit of finished code
• The 'hardest problem' reflection names a specific error message or behaviour, what the submitter tried, and what eventually worked

Common mistakes

• Building a tutorial project ('I built a to-do list because the tutorial used a to-do list') — the problem must come from your life, not the internet
• One-commit repository — version control is not an afterthought, it is how professionals work, and the commit history shows whether you built incrementally or copy-pasted a finished solution

Resources

What a verifier looks for

• Clone the repository and run the program following only the README instructions — if you cannot run it in under 5 minutes using only the README, it is not complete
• Check the commit history — more than 5 commits with meaningful messages signals that this was built incrementally, not one commit of finished code
• Watch the screen recording: does the submitter narrate what they built or just click through menus? Narration reveals understanding

Proof required

Share the public URL of your deployed application or the PyPI package link. Share evidence that 5 real users tried it: screenshots of their feedback (messages, emails, form responses — anonymised is fine). Write 200 words on what you changed after the first person used it and what you learned about the difference between building for yourself and building for others.

What gets checked

• Public URL or PyPI link works without the submitter helping — a stranger can find it and use it independently
• 5 users are real people who found it without being personally asked by the submitter — posted in a community, shared on social media, or submitted to a directory
• The 'building for yourself vs others' reflection is specific — names one concrete thing that confused a real user that the submitter had never considered

Common mistakes

• Counting friends and family as the 5 users — they are too polite to give honest feedback, which defeats the purpose of this milestone
• Deploying but not sharing it anywhere — 'I put it on the internet' is not the same as 'I got strangers to use it'; share in communities (Reddit, Discord, HackerNews Show HN) to find real users

Resources

What a verifier looks for

• Visit the URL without any help from the submitter — try to use the program as a complete stranger would and note every point of confusion
• Verify the 5 users are real people who found it without being personally invited — posted in a community, shared on social media, or submitted to a directory; friends and family do not count
• Compare your experience as a stranger to what the submitter said confused their users — if you found new problems they didn't mention, ask why those weren't addressed