Ship Something Real — Python Milestone Project

This is the project that proves you can ship production-quality Python end to end. Your goal is to choose one track, design a small real thing, build it, test it, document it, version it with Git, package it, and present it like work you would proudly show in an interview.

You are not building a toy to finish a lesson. You are building a small finished product: narrow, useful, tested, explained, and shaped well enough that future-you could keep improving it.

What you'll build

Choose one track:

Web app: a browser-facing program with routes, request/response behavior, and stored data.
Data pipeline: a program that loads raw data, cleans it, transforms it, and produces a trustworthy output.
CLI tool: a command-line tool with arguments, helpful output, and clear exit behavior.
Reusable library: a package other Python code can import, with a small public API and docs.
Automation system: a repeatable script that safely handles files, APIs, reports, or local workflow steps.

A capstone is a final project that ties together the skills from the course. A production-quality project is not perfect or huge; it is understandable, tested, documented, and honest about its limits. A ship target is the specific way someone can run, inspect, or use your finished work.

Pick a project small enough to finish in a week of focused work. A narrow finished tool beats a giant half-built platform.

The scaffold below is your planning workspace. It does not build the final project for you. It helps you choose the track, define the user, write acceptance criteria, and check that your plan covers design, build, tests, docs, Git, packaging, and shipping.

python — playgroundlive

TRACKS = {
  "web_app": "Browser-facing app with routes and stored data",
  "data_pipeline": "Load, clean, transform, and explain data",
  "cli_tool": "Command-line tool with arguments and useful output",
  "library": "Importable package with a small public API",
  "automation": "Repeatable workflow script with safety checks",
}

project = {
  "name": "Practice Coach",
  "track": "cli_tool",
  "user": "Maya, a student tracking daily Python practice",
  "problem": "Maya forgets which topics she practiced and what to review next.",
  "ship_target": "A local command-line tool with demo data, tests, docs, and one clear way to start it.",
}

acceptance_criteria = [
  "A user can add a practice session with topic, minutes, and mood.",
  "A user can list sessions and see total minutes by topic.",
  "Bad minutes input shows a friendly error instead of a traceback.",
  "Tests cover adding, listing, totals, and bad input.",
]

def show_track_options():
  print("Available tracks:")
  for key, summary in TRACKS.items():
      print(f"- {key}: {summary}")

def validate_project(project, criteria):
  required_fields = ["name", "track", "user", "problem", "ship_target"]
  missing = []

for field in required_fields:
      if not project.get(field):
          missing.append(field)

if project.get("track") not in TRACKS:
      missing.append("track must be one of the listed track keys")

if len(criteria) < 3:
      missing.append("write at least 3 acceptance criteria")

return missing

def print_project_brief(project, criteria):
  print("Capstone brief")
  print("Name:", project["name"])
  print("Track:", project["track"])
  print("User:", project["user"])
  print("Problem:", project["problem"])
  print("Ship target:", project["ship_target"])
  print()
  print("Acceptance criteria:")
  for number, criterion in enumerate(criteria, start=1):
      print(f"{number}. {criterion}")

show_track_options()
print()
print_project_brief(project, acceptance_criteria)
print()

missing = validate_project(project, acceptance_criteria)
if missing:
  print("Plan gaps:")
  for gap in missing:
      print("-", gap)
else:
  print("Plan check: ready to design the first milestone.")

# TODO: Replace the sample Practice Coach idea with your own.
# TODO: Add one acceptance criterion for tests and one for documentation.
# TODO: Keep the first build small enough to finish before adding stretch goals.

⌘/Ctrl + Enter to run

Checkpoint 1: choose the track and narrow the promise

Start by choosing one track and one user. Do not start with features. Start with the problem.

Acceptance criteria:

You can name the track: web app, data pipeline, CLI tool, reusable library, or automation system.
You can describe one real user in one sentence.
You can describe the problem without naming a technology.
You can write a ship target: how someone will run, inspect, or use the finished project.
The first version is small enough that you can explain it in under one minute.

Use Part I here. Your project still follows input -> process -> output. If you cannot state those three pieces, the project is too foggy.

Checkpoint 2: design the core before the edges

Write the core rules first. A web app route, CLI parser, notebook, file watcher, or API call is an edge. The core is the part that answers the real question: "What should happen?"

Acceptance criteria:

You have a short design note with the main data shape: strings, numbers, lists, dictionaries, classes, files, database tables, or DataFrames.
You have at least three acceptance criteria written as user-visible behavior.
Your core rules can run without a live network, cloud account, package upload, or hidden local setup.
You can point to one design choice from Design Patterns in Python or Principles of Good Design.
You know what you are deliberately not building yet.

For a web app, this might mean testing the route handler's data rule before worrying about hosting. For a data pipeline, it might mean cleaning a small sample string before reaching for a large file. For a library, it means designing the public function names before packaging polish.

Checkpoint 3: build the smallest useful version

Build the MVP, or minimum viable product: the smallest version that solves the central problem for the user. This is where you pull from every earlier part of the course.

Acceptance criteria:

The program has a clear entry point, meaning the place where a user or tool starts the program.
The happy path works from start to finish.
Bad input has a specific response, not a mystery crash.
Data is stored in the right place for the track: memory, files, SQLite, JSON, CSV, or another shape you can explain.
The code is organized into functions, classes, or modules with honest reasons to change.

Use Part II for functions, files, JSON, CSV, and exceptions. Use Part III for classes, dunder methods, decorators, iterators, context managers, regex, or time handling when they make the design clearer. Use Part V when your track is data, database, web/API, automation, CLI, or AI-adjacent.

Checkpoint 4: prove it works

Testing is where your project starts acting like professional work. You are not trying to test every line. You are preserving the behavior that would embarrass you if it broke.

Acceptance criteria:

You have automated tests for the core rule.
You have tests for at least one bad input or failure path.
You can run the project from a fresh terminal and explain the setup.
You have used formatting, linting, or type feedback where it helps readability.
You have read your own Git diff before calling the project done.

Use Part IV here: tests, debugging, logging, profiling when needed, Git history, CI/CD shape, and AI as a careful assistant. If AI helped, keep the verification trail: what you asked, what changed, and what checks passed.

Checkpoint 5: document, package, and ship

Documentation is writing that helps someone use, understand, or maintain the project. Packaging is arranging code and metadata so the project can be installed, imported, or run predictably. Shipping means making the finished work available in the agreed form.

Acceptance criteria:

The README, a front-page project file, explains the problem, setup, usage, examples, tests, and limitations.
The project has a clean file structure and a clear project root.
Secrets, caches, virtual environments, build output, and local data are not committed.
Version history uses meaningful Git commits.
The ship target works: a local demo, a package build, a hosted preview, a sample output file, or a recorded walkthrough.
The final notes say what you would improve next, not because the project is broken, but because real software keeps growing.

Do not turn "ship" into live cloud work if that distracts from the project. A self-contained demo with clear docs, tests, and version history is a valid ship target.

Stretch goals

Choose only after the base project ships:

Add one extra interface: a CLI for a library, an HTML page for an API, or a report file for an automation.
Add richer persistence: SQLite tables, JSON import/export, or CSV reporting.
Add logging around key actions.
Add type hints and run static type feedback.
Add a small CI workflow shape in your repository docs.
Add one performance measurement if the project handles enough data to justify it.
Add a design note explaining one trade-off: composition over inheritance, Factory vs direct construction, or clean core vs edge code.

How to get unstuck

If the project idea feels too big, shrink it with the Part I input -> process -> output pattern from What Is Programming? and the menu patterns from Loops & Iteration. If your data shape gets messy, go back to Choosing the Right Data Structure, File Handling, and Structured Data Files. If behavior is scattered, rebuild it with Defining & Calling Functions, Classes & Instances, and Encapsulation.

If the project feels fragile, return to Errors & Exceptions, Testing Fundamentals, and Going Deeper with Testing. If the project will be shared, use Structuring a Real Project, Packaging & Publishing, and Git Fundamentals. If you are building a track-specific project, revisit the Part V lessons for Data Workflow, Python and Databases, Building Web Apps and APIs, Building Real CLI Tools, or Building with AI APIs.

If your design starts to sprawl, compare it to Design Patterns in Python, Principles of Good Design, and Becoming a Python Professional. Your capstone is done when a stranger can read the README, run the project, see the tests pass, and understand why the design is shaped the way it is.

After you ship: earn your certificate

Shipping the capstone is the last lesson — proving it all stuck is the Python Final Exam. It is 60 questions in 120 minutes, 15 of them real code graded by running it, and it unlocks once you have completed 70% of the course. Pass it and you get a shareable, verifiable Certificate of Completion you can put on LinkedIn next to this very capstone. Free, unlimited retakes.