First Three Projects Shipped (Beginner to Public App)

Proof required

Share a screenshot of the terminal running both programs with real input and output. Use the terminal, not a code editor. Write 100 words on what happens as Python runs your code line by line. Use your own words, not a tutorial's.

What gets checked

• The terminal shows real input typed in, not a snippet or editor preview.
• The explanation is in your own words and traces the execution, even if imperfectly.
• Both programs run without errors, and the birth year is correct.

Common mistakes

• Installing an IDE before writing any code. Open the terminal first.
• Copying the program instead of typing it. Typing is how syntax sticks.

Resources

What a verifier looks for

• The screenshot must show the program running with visible input. Reject it otherwise.
• Ask them to read the explanation aloud. Can they say what input() does and why print() needs it?
• If it's vague, ask them to handle someone typing their age as a word. Their answer shows understanding.

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

Proof required

Share all three programs through a public link. A Gist, Replit or pastebin works. Run each in your terminal and share the output. Write 150 words on the data structure that confused you most. Say what you understand now.

What gets checked

• All three problems are your own, not tutorial exercises or the examples named here.
• Each program has a loop and a conditional, visible in the code.
• The reflection names a specific confusion, like why dictionaries use keys, not positions.

Common mistakes

• Using the example problems named here. Choosing your own makes you think about what each structure is for.
• Three programs that are the same problem with different variable names.

Resources

What a verifier looks for

• Read the code, not just the output. The loop should go over the data structure.
• Check the three programs solve different problems, and aren't the examples named here.
• Ask why they used a dictionary, not a list. 'The tutorial did' means it hasn't landed yet.

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

Proof required

Share the reworked code through a public link. Share a screenshot of it handling three kinds of bad input. Each gets a helpful message. Write 150 words on what trying to break it taught you. Which assumptions had you made without noticing?

What gets checked

• Each function does one thing. One that reads, validates and processes input is doing three.
• Error handling uses try/except properly, not just if/else checks that miss cases.
• The reflection names specific assumptions, like 'the user always types a number'.

Common mistakes

• Functions that are just renamed blocks. One function doing everything is a renamed main().
• Catching everything with a bare except:. Catch specific errors like ValueError instead.

Resources

What a verifier looks for

• Run it yourself with letters, empty input and a very long string. A crash means it's incomplete.
• Read the functions. Each must do one thing.
• Ask them to name one function's single job. If they struggle, the split didn't work.

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

Proof required

Share a GitHub repository with a README, not a Gist. The README says what it does, how to run it and why you built it. Record a 2-minute screen video running it and explaining what it does. Write 200 words on the hardest problem you hit. Say what failed before what worked.

What gets checked

• It solves a problem you named first. 'Why I built this' is personal, not 'to practise Python'.
• At least five commits show it built step by step, not one final commit.
• The reflection names a specific error, what you tried, and what finally worked.

Common mistakes

• A tutorial project, like a to-do list because the tutorial had one. The problem must be yours.
• A one-commit repository. Commit history shows you built it step by step.

Resources

What a verifier looks for

• Clone it and run it from the README alone. If that takes over 5 minutes, it isn't done.
• Check for more than five commits with meaningful messages.
• Watch the video. Do they explain what they built, or just click through?

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

Proof required

Share the public URL or the PyPI link. Show five real users tried it, with screenshots of their feedback. Messages, emails or form replies all work. Anonymised is fine. Write 200 words on what you changed after the first user. Say what you learned about building for others.

What gets checked

• The URL or package works for a stranger with no help from you.
• The five found it without a personal invite, through a community, social post or directory.
• The reflection names one real confusion you'd never considered.

Common mistakes

• Counting friends and family. They're too polite to be honest.
• Deploying but not sharing it. Post it in communities like Reddit, Discord or Show HN.

Resources

What a verifier looks for

• Use it yourself with no help, as a stranger. Note each point of confusion.
• Check the five found it without a personal invite. Friends and family don't count.
• Compare your confusions with theirs. If you found new ones, ask why they weren't fixed.

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