Milestone map
Milestone map
3 milestones
Deploy a working prototype to a real URL
2–4 weeks
Define the specific problem your AI product will solve, build a working prototype that addresses it, and deploy it to a URL real users can access. The prototype does not need to be polished — it needs to work and be reachable without a local setup. Identify the core AI component (model call, retrieval pipeline, fine-tuned classifier, agent loop) and confirm it is load-bearing: remove it and the product's primary value disappears.
Proof required
Submit: (1) a live URL accessible by anyone right now, (2) a 2-paragraph write-up naming the problem it solves and the specific AI component driving it (not 'I used GPT-4' but the retrieval design, prompt chain, or model choice and why), and (3) one screenshot of the product in use.
What gets checked
- URL is live, accessible without credentials, and the AI component is interactive — a static page or a link to a GitHub repo is not a deployed product
- Problem statement is specific: names who has the problem, what they currently do instead, and why the AI approach improves on that — 'helps people do X faster' is too vague
- AI component is load-bearing: submitter can articulate what the product does differently when the model responds differently — if they cannot, the AI is decorative
Common mistakes
- Spending weeks on architecture before deploying anything — a prototype that runs only on localhost is not shipped; deploy early and iterate
- The AI feature is incidental — used in one optional step while the core product would work fine without it
- Confusing 'it works on my machine' with 'it is deployed' — Vercel, Render, Hugging Face Spaces, and Replit all offer free hosting that takes minutes to configure
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Open the URL yourself right now — if it is unreachable, this milestone is not met regardless of the write-up quality
- Ask: what happens if you remove the AI component — does the product stop working? If the answer is 'not really', the AI is decorative
- Ask the submitter to explain their specific model or retrieval choice in one sentence — 'I used the API' is not sufficient; 'I used GPT-4o with a sliding-window chunker because the documents are long and context ordering matters' is
You'll sign in first, then come straight back here.
Get 5 real users and document their feedback
1–3 weeks
Reach at least 5 people who actually have the problem your product addresses — not people doing you a favour — get them to attempt a real task using the product, and document what they said. Feedback from people with the problem is evidence; feedback from supportive friends is noise. Their responses will tell you whether the AI component is actually useful or merely impressive.
Proof required
Submit a feedback log with 5+ entries, each showing: how you found this user (not 'friend' alone — explain why they have the problem), what task you asked them to complete, verbatim or close-paraphrase of what they said, and one thing you changed or plan to change as a result. A spreadsheet, doc, or structured note are all acceptable formats.
What gets checked
- 5 entries with real recruitment context — 'colleague who does X daily' or 'found via Reddit community for Y' is credible; 'my friend who is generally supportive' is not
- Each entry shows a specific task the user attempted — not 'I showed them the product' but 'I asked them to [do X] and watched what happened'
- At least one entry documents something that frustrated or confused the user, and the submitter has a concrete response to it — a feedback log with no friction is a screened audience
Common mistakes
- Counting people who watched a demo as users — they need to attempt a task independently, not observe you demonstrating
- Recruiting only people likely to be positive — the purpose is to find what breaks, not to confirm it is good
- Logging feedback but drawing no conclusions — a list of quotes without 'here is what I changed because of this' is incomplete
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask how each user was recruited — 'friend' alone is not sufficient; the verifier should probe whether the user had the actual problem the product is solving
- Feedback log should show friction — if every user found the product clear and delightful with no confusion, the recruitment was too friendly
- Ask the submitter what they changed based on one specific piece of feedback — if they cannot point to a change, the feedback was not acted on
You'll sign in first, then come straight back here.
Prove retention: 10 users returning across 4 weeks
4–6 weeks (runs concurrently with M2 user-recruitment period)
A product used once and abandoned is a demo. This milestone requires evidence of genuine retention: at least 10 distinct users who have used the product on more than one occasion, observed across at least 4 calendar weeks. Analytics, API logs, or a verifiable usage record are the proof standard — self-reported counts without a timestamp trail do not pass. The AI component must be the reason people return, not an incidental feature they bypass.
Proof required
Submit: (1) usage data covering at least 4 weeks — an analytics screenshot, server log excerpt, or usage dashboard — showing at least 10 distinct users with at least one return visit each, (2) a brief note on which AI feature drives return visits and how you know, and (3) one user quote or message showing they found the product useful in their actual workflow.
What gets checked
- 10 distinct users identified (not 10 visits from 3 users) — the data source must distinguish users, not just count requests
- 4-week span is genuine — dates in the data must span at least 28 calendar days; a burst of usage in 48 hours does not qualify
- AI feature is what drives return use — submitter can explain why users come back specifically for the AI capability, not for a non-AI feature it also happens to have
Common mistakes
- Treating unique page views as unique users without a user identity signal — page views can come from the same person refreshing; use session IDs, login counts, or API keys to distinguish users
- The product has repeat usage but for a non-AI reason — if users return for a directory or a static tool and never trigger the AI component, retention is not proof of the AI product working
- 4 weeks elapsed on the calendar but actual usage is clustered in one week — calendar time is the minimum condition; active use spread across weeks is the real bar
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask for the raw data source — analytics dashboard, server log, or equivalent — not a summary the submitter has written; the summary could be inaccurate
- Confirm the user count method: ask how the data distinguishes one user from another (session ID, login, API key, device fingerprint) — page view counts do not suffice
- Ask which specific AI feature appears in the return-visit sessions — if the verifier cannot identify it in the data or the submitter cannot point to it, the retention may be for a non-AI reason
You'll sign in first, then come straight back here.
Part of