Milestone map
Milestone map
3 milestones
Build and deploy your first working project
4 weeks
The first section of any coding bootcamp covers the foundational layer of your chosen stack — HTML/CSS/JavaScript for web, Python for data science, or equivalent. The goal of this milestone is your first deployed project that a stranger can visit and use. Complete the bootcamp's introductory modules, then build the first assigned project without copying the provided solution. Push every commit to a public GitHub repository with meaningful commit messages — the commit history should show a learning arc, not a finished file dropped in.
Proof required
Submit a live URL of your first bootcamp project (hosted on GitHub Pages, Vercel, Netlify, or equivalent free host) alongside a link to its public GitHub repository. The repository must show at least 5 commits with descriptive messages and a README that explains what the project does and how to run it.
What gets checked
- Project runs without errors when the live URL is visited — no broken layouts, console errors that block functionality, or missing assets
- GitHub repository shows a genuine learning commit history: at least 5 commits, varied messages (not 'initial commit' with all files), with evidence of iteration
- README explains the project's purpose and tech stack in plain language — a stranger who visits the repository can understand what they're looking at
Common mistakes
- Watching tutorials without writing code — passive consumption produces zero transfer; pause the tutorial after 2 minutes, attempt the exercise yourself, then return to check
- Copying the bootcamp's solution code to move quickly — a project built from copied code cannot be explained in a follow-up review, which makes M3's code review impossible to pass
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Visit the live URL yourself and test the core functionality — do not accept a screenshot
- Check the GitHub commit history: meaningful messages, chronological progression, evidence of bugs fixed across commits rather than a one-shot dump
- Ask the submitter to walk you through their most complex function — someone who coded it can explain line-by-line; someone who copied it cannot
You'll sign in first, then come straight back here.
Ship a multi-layer project with documented architecture
6 weeks
The midpoint of a bootcamp introduces your stack's second layer — a backend API, a database, a state management library, or an advanced framework. The milestone is a project that combines at least two technology layers and is deployed to a public URL. The proof requires a written architecture description of 150 words minimum explaining your technology choices and one specific technical problem you solved — not just listing what you used, but explaining why and how.
Proof required
Submit a live URL of a working multi-layer project built during your bootcamp (no localhost screenshots), a public GitHub repository, and a written description (150 words minimum) naming the technologies used, explaining why each was chosen, and describing one concrete technical problem you solved during the build.
What gets checked
- Live URL is publicly accessible and demonstrates working integration between at least two technology layers (e.g. frontend that fetches from an API, or UI that reads/writes to a database)
- Written description explains WHY each technology was chosen — not just listing them, but articulating a decision (e.g. 'I chose Postgres over SQLite because the project requires concurrent writes')
- Technical problem described is specific: names the error, the attempt that failed, and what ultimately worked — not 'I had some challenges with the API'
Common mistakes
- Building a project identical to the bootcamp tutorial walkthrough — the project should diverge from the course example in at least one meaningful way that required you to solve a new problem independently
- Skipping deployment and submitting a localhost screenshot — external verifiability is non-negotiable; use Vercel, Render, Railway, or equivalent free tier
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Visit the live URL and test the cross-layer functionality yourself — click through the core user journey
- Ask the submitter to describe a technical decision that was NOT in the bootcamp curriculum — original decisions require genuine understanding of the tradeoffs
- Check the GitHub repository for debugging commits, branch attempts, or merge conflict resolutions that indicate real development rather than a one-shot file drop
You'll sign in first, then come straight back here.
Capstone reviewed by a working engineer
4 weeks
The capstone marks bootcamp completion and is the primary employability signal. The proof is NOT the bootcamp certificate — it is your capstone project reviewed by a qualified engineer who did not teach the bootcamp. They should run the project, read the code, and ask follow-up questions about implementation decisions you made. Document their name, their professional background (minimum 3 years industry experience in the relevant stack), the date of the review, what sections they examined, what follow-up questions they asked, and your responses. A bootcamp certificate submitted without this review does not pass this milestone.
Proof required
Submit your capstone project (live URL + public GitHub repository) alongside a written review report documenting: the reviewer's name and professional background (with a verifiable link such as LinkedIn), the specific code sections they examined, at least two follow-up questions they asked and your written answers, and their overall assessment of the project's technical quality.
What gets checked
- Reviewer is identified by full name with a verifiable professional background (LinkedIn profile, employer website, or GitHub with public employment history) showing at least 3 years in the relevant language or framework
- Written review documents at least two specific technical questions the reviewer asked — not general feedback, but questions about specific implementation decisions, and the submitter's written responses
- Capstone project demonstrates a complete user journey: a first-time visitor with no prior context can open the live URL and complete the project's core task without assistance
Common mistakes
- Asking a bootcamp instructor, cohort peer, or personal friend to verify — the reviewer must be someone employed as a developer, engineer, or technical lead who has no prior involvement in your bootcamp or learning journey
- Using AI-generated code in the capstone without understanding it — the reviewer's follow-up questions are specifically designed to surface this; if you cannot explain code you submitted, the review will expose it
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the code reviewer has no prior connection to the submitter's bootcamp — ask directly if the reviewer was the submitter's instructor or cohort peer
- Ask the submitter to explain one component of the capstone project in detail and without preparation — if they coded it, they can explain it; inability to explain their own code is a clear signal
- The reviewer's LinkedIn or GitHub should show at least 3 years of professional engineering work in the stack the capstone uses — a junior developer or self-taught peer does not meet the qualification threshold
You'll sign in first, then come straight back here.