THE MILESTONES

One project.
15 milestones to deliver it.

You build one thing for sixteen weeks. Each milestone hands you the next piece of it — the charter, the requirements, the specification, the plan, the build, the tests, the documentation, the release, the talk. Three tiers each: Normal, Medium, Hard.

Week 1 · Inception

Project Charter & Engineering System

"What does it cost to finish what you start?"

What a capstone actually is; the modern software development life cycle and the seven hats a solo capstone forces you to wear; the 240-hour budget and where it goes; and standing up your engineering system — repository, project board, and hours log — in Week 1, before you have an idea→

Week 2 · Inception

Idea Portfolio & Scoping Decision

"How do you tell a worthy work from a vain one?"

Generating candidate ideas from problems rather than technologies; testing an idea for feasibility, scope, novelty, and evidence of a real user; the arithmetic of right-sizing to 240 hours; and killing two of your three candidates on purpose→

Week 3 · Requirements

Software Requirements Specification v1

"What makes a word trustworthy?"

Elicitation from stakeholders; personas and user stories; functional requirements written so that a stranger could verify them; acceptance criteria; unique identifiers and priority with MoSCoW; and a long side-by-side gallery of bad requirements rewritten into good ones→

Week 4 · Requirements

Non-Functional Requirements, Constraints & Definition of Done

"Who is my neighbor when I write software?"

Non-functional requirements made measurable — performance, reliability, security, privacy, accessibility, usability, maintainability, portability; constraints and assumptions; licensing and data obligations; the requirements traceability matrix; and a definition of done you will actually be held to→

Week 5 · Design

Technology Evaluation & Architecture Decision Records

"Why does wisdom test a thing before trusting it?"

Evaluating technologies against your requirements instead of against fashion; integration risk and the cost of learning four new things at once; build versus buy; hosting, cost, and licensing; and recording the decision permanently in architecture decision records→

Week 6 · Design

Technical Specification (System Design Document)

"What are you building on?"

Turning requirements into a buildable design: context and component diagrams, module responsibilities, interface and API contracts, the data model, sequence flows for the critical paths, error handling and edge cases — with good and bad specifications shown side by side→

Week 7 · Planning

Work Breakdown, Schedule & Risk Register

"Why does a plan need humility?"

Wearing the project-manager hat: decomposing the specification into a work breakdown, estimating tasks when you have never done them before, scheduling against the hours you actually have, tracking with a burn-down, and running a risk register with owners, triggers, and responses→

Week 9 · Construction

Walking Skeleton & Continuous Integration

"Why lay a foundation before you decorate?"

Construction begins with the thinnest possible end-to-end slice: repository structure, branching and commit discipline, a reproducible development environment, continuous integration that runs on every push, issue tracking wired to your requirements, and one real request travelling the whole system→

Week 10 · Construction

Core Increment & Demo

"Whose work is it when a machine helps you?"

The developer hat at full speed: working in vertical slices, a per-task definition of done, code review when you are the only reviewer, AI-assisted implementation with real accountability, and keeping the hours log honest while you are too busy to keep it→

Week 11 · Verification

Test Plan, Test Suite & Defect Log

"Why does an honest builder look for his own faults?"

Verification as a phase, not an afterthought: the test plan, unit and integration and acceptance levels, traceability from requirement to test case, test data, defect reporting and triage by severity and priority, regression discipline, and knowing when quality is good enough→

Week 12 · Construction

Integrated Release Candidate & Change Log

"When is it right to say no?"

Integrating the pieces and confronting what you deferred: performance against your own targets, a security pass, third-party failure modes, and the discipline of change control — accepting, deferring, or refusing scope with a written impact analysis instead of a shrug→

Week 13 · Documentation

Documentation Set & the Clean-Machine Test

"What does it mean to entrust your work to another?"

Writing the documentation set that carries the largest share of your grade and all of your project's future: the README that actually gets a stranger running, the architecture overview, the runbook, the onboarding guide, the decision record index, and the clean-machine test that proves any of it works→

Week 14 · Transition

Deployable Release v1.0 & Handoff Package

"Who inherits what you built?"

Making the project run somewhere that is not your laptop and continue without you: configuration and secrets, scripted or containerized setup, deployment and rollback, versioning and release tagging, licensing the repository, and assembling the handoff package that lets the next engineer take over→

Week 15 · Delivery

Presentation Deck, Demo Script & Rehearsal

"How do you tell the truth about your own work?"

Building and rehearsing the presentation that carries 10 percent of your grade: the arc from problem to result, allocating thirty minutes honestly, slide design that survives a projector, demo discipline and the recorded fallback, answering questions you cannot answer, and telling the truth about what did not get done→

Week 16 · Delivery

The Final Submission

"What makes work finished?"

Closing the project: the final submission checklist run against the grading rubric, tagging and submitting the repository link, delivering the talk, and the retrospective that turns sixteen weeks into something you can carry into an interview and a career→