Milestone map
Milestone map
3 milestones
Define the tool's purpose and build the core interaction
4–8 weeks
Define what the creative coding tool does and for whom, and build the core interaction that makes it useful. A creative coding tool is a piece of software — not necessarily a polished product — that enables a specific kind of creative expression that would otherwise be significantly harder or impossible without it. The core interaction is the one thing the tool does that no other freely available tool does in the same way. This can be a generative art tool, an interactive audio visualiser, a procedural pattern generator, a typeface tester, a constraint-based writing tool, or any other software where the code is itself creative and the tool enables creativity.
Proof required
Share a publicly accessible URL where the tool can be used (a web app, a GitHub Pages deploy, a CodePen, or a downloadable binary with instructions). State in 2 sentences what the tool does and who would use it. Demonstrate the core interaction by sharing a screenshot or GIF of the tool in use.
What gets checked
- Tool accessible at the shared URL — a verifier can open and use it without instructions.
- Purpose stated in 2 sentences — not 'a tool for creative things' but a specific use case and user.
- Core interaction demonstrated via screenshot or GIF.
Common mistakes
- URL requires a sign-up or download to test: 'you can download it from my repo' — the tool must be usable without friction for the verifier.
- Purpose too vague: 'it generates art' — what specifically does it generate, and who would use it instead of existing tools?
- Core interaction absent from the proof: only a code repository linked without a demo or screenshot.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Open the tool and interact with it — does the core interaction work without reading documentation?
- Purpose specificity: ask the creator what problem or creative limitation this tool solves — 'I wanted to be able to do X and no existing tool let me do it the way I wanted' is a real answer.
- Comparison to existing tools: ask what the creator considered before building this, and what made them decide to build their own — this reveals whether the tool addresses a genuine gap or duplicates something readily available.
You'll sign in first, then come straight back here.
Add one meaningful feature and share the tool publicly
2–6 weeks after M1
Add one meaningful feature that makes the tool more useful or expressive than the M1 version, and share it with at least one community outside the creator's personal network. The feature addition is not about polish — it is about deepening the tool's core capability. The external share is critical: it is the first time the tool exists for people who did not watch it being built, and their response (or lack of response) is a real signal about whether the tool has value to others.
Proof required
Share the updated tool URL and describe the one feature added since M1 in 2 sentences. Share evidence of the external share — a Reddit post, a tweet/post, a submission to a creative coding community (Processing Foundation forums, r/generative, r/creativecoding, OpenProcessing, or similar). State how many people interacted with it.
What gets checked
- Feature added and described — must be a new capability, not a bug fix or visual polish.
- Evidence of external share in a community outside the creator's personal network.
- Interaction count stated — even 'zero interactions' is a valid answer.
Common mistakes
- Feature added but not described: 'I improved it' without stating what changed and why it matters.
- Only shared with personal contacts: 'I showed it to my friends' — external community share is required.
- Interaction count absent: 'I posted it' without any note on how many people saw or used it.
Resources
What a verifier looks for
- Feature description: ask what the tool can now do that it could not do before — the answer should be a specific capability, not just 'it's better.'
- External community: ask where specifically the tool was shared — a named subreddit, a named forum, or a named platform. 'I posted it on social media' to personal followers is not an external community share.
- Zero interactions: if no one engaged, ask whether the creator learned anything about why — submission timing, wrong community, tool not polished enough? This reflection is more valuable than the interaction count itself.
You'll sign in first, then come straight back here.
Document the tool and reflect on what you built
1–3 weeks after M2
Write documentation for the tool (a README or a brief user guide) that allows someone who has never seen it to understand what it does, how to use it, and what creative possibilities it offers. Write a reflection on what you learned from building this specific tool — what surprised you technically, what surprised you about how people responded to it, and what you would build next. The documentation is the proof that the tool has been completed, not abandoned; the reflection is the proof that the build was a real learning experience.
Proof required
Share the tool URL with documentation — a README in the repository or a brief written guide linked from the tool. Share your reflection (minimum 200 words) on what you learned technically and from any user feedback. State one thing the tool can do that you did not plan when you started building it.
What gets checked
- Documentation accessible — README in the repository or linked from the tool page.
- Reflection is minimum 200 words and addresses both technical learning and user/community response.
- One unplanned capability identified — demonstrates emergent discovery in the building process.
Common mistakes
- Documentation absent: 'the code is the documentation' — a README or user guide is required.
- Reflection under 200 words or generic: 'I learned a lot about creative coding' — the reflection must be specific to this tool.
- Unplanned capability absent: 'I built exactly what I planned' — almost every creative coding project develops unexpected capabilities; their absence in the reflection suggests shallow engagement with the build.
Resources
What a verifier looks for
- Read the documentation: can a new user understand what the tool does without any additional explanation? The documentation test is whether a stranger could use the tool productively in 5 minutes.
- Reflection specificity: ask the creator to name the most surprising technical problem they encountered — vague answers suggest the reflection was written without much thought.
- Unplanned capability: ask the creator to demonstrate the unplanned capability in the tool — it should be real and visible, not described in the abstract.
You'll sign in first, then come straight back here.
Part of