Phase 7: Capstone · ~90 minutes · Python · FastAPI · SQLite
Build It
Git-tracked from commit one, environment-isolated, tests written alongside the code, not after. This is the same build discipline as Course 01's capstone, now applied to a real networked service.
Hiring signal: Builds with tests alongside the code and a clean git history from the very first commit, not bolted on at the end
What you will learn
- Implement a real service from a written design, git-tracked from the first commit
- Write tests alongside the implementation, not after it's 'done'
- Use an isolated environment (uv) and environment-variable config from the start
- Apply Phase 05's debugging discipline when something breaks
Introduction
Type: Project Languages: Python, FastAPI, SQLite Prerequisites: Lesson 01 (Design the Service) Time: ~90 minutes
Objective
Learning objectives
- Implement a real service from a written design, git-tracked from the first commit
- Write tests alongside the implementation, not after it's "done"
- Use an isolated environment (
uv) and environment-variable config from the start - Apply Phase 05's debugging discipline when something breaks
What you're building
Your own designed service from Lesson 01:
- Initialize a real git repository, first commit before any real implementation exists (an empty scaffold is a legitimate first commit)
- Set up an isolated
uv environment with your real dependencies - Implement each endpoint from your design, writing its tests immediately after (or alongside) that endpoint, not in one batch at the end
- Read configuration (at minimum, your database path) from an environment variable, never hardcoded, per Lesson 01's plan
- Run your full test suite for real (
pytest -v) and confirm every planned test passes - If something breaks along the way, use Phase 05's escalation ladder — cheapest tool first — and note in a comment what actually went wrong and how you found it
A developer implements all 5 endpoints of a service first, writes zero tests during that process, then plans to "add tests at the end." What's the most likely real cost of this approach, per this lesson?
This is exactly this lesson's central warning. Tests written well after implementation, in a single batch, are written by someone who has already internalized how the code currently behaves — including any bugs — making it easy to unconsciously write tests that match the existing (possibly wrong) behavior rather than checking it against what Lesson 01's design actually specified. Writing tests alongside each piece of implementation, while the intended behavior is still the explicit reference point, is a real, meaningfully different practice, not just a scheduling preference.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy