Capstone: One Cadence Feature from Idea to Production
Every chapter showed one slice of building software. This capstone threads them into a single story: Cadence's daily reminders feature, followed through the entire lifecycle from a first idea to live, monitored production. It's the whole book in one worked example — and proof that the pieces connect.
Watch how each thing you learned shows up, in order, on one real feature. By the end, the separate ideas should feel like one continuous craft.
Idea → Requirements
It starts with a problem, not a feature (Chapters 1–4). Priya's discovery interviews reveal that users don't want more features — they simply forget to open the app. That insight becomes a user story: "As a user, I want a daily reminder so I don't forget my habit," with acceptance criteria — fires at the chosen time, tappable, off by default. Reminders rise to the top of the backlog as the next "Must". The team has turned a vague pain into a clear, buildable, testable piece of work.
Design → Build → Review
Next, shape and craft (Chapters 5–8). The team designs reminders as a focused module depending on a generic "notifier" abstraction (low coupling, the SOLID "D"), so email or push can slot in later. Lena builds it as clean, well-named code on a reminders branch, committing as she goes, and opens a pull request. Marcus reviews it, catches an edge case — what if the chosen time is in the past? — and they fix it together before it merges. Two people now understand the code.
Test → Ship
Then prove it and ship it (Chapters 9–10). Marcus writes the tricky "streak resets after a missed day" logic test-first; the feature gets unit tests on the timing, integration tests on saving, and an end-to-end test of the whole flow — a healthy pyramid. Every push runs through CI; the PR can't merge until it's green. The build produces one versioned artifact, promoted through staging to production, released behind a feature flag to a 5% canary, then widened to everyone — with rollback ready.
Run → Learn
Finally, run it and learn (Chapters 11–14). In production, observability watches reminders via logs, metrics, and traces, against an SLO of "99% fire within one minute". One night they fire late; the on-call engineer mitigates with the flag, and a blameless postmortem finds a missing alert — added, not blamed. The team's DORA numbers stay healthy, the code is documented for the next person, and the feature settles into maintenance. From "users forget" to a reliable, watched, improving feature — every phase of this book, on one small reminder.
- "Building software is mostly the coding part." The code was a small slice of this story — discovery, design, review, testing, releasing, and running it filled most of the journey. That's the whole point of the course.
- "The feature was done when it shipped." Shipping was the middle. Running it, watching it, recovering from the late-reminder incident, and maintaining it is where most of its life happens.
- "Each phase is a separate, unrelated activity." They connect into one flow — the user story shaped the tests, the design enabled the swap, the flag enabled the safe release. The phases are one continuous craft, not silos.
- Synthesis is what turns sixty-one separate ideas into one coherent mental model — the course's promise that no questions remain about how software is made.
- Seeing one feature flow through every phase shows that the practices aren't a checklist but a connected craft, each step setting up the next.
- You now have the whole map: from here, you fill it in with practice — building, shipping, and running real software, one feature at a time.
Knowledge Check
Where did the reminders feature actually begin?
- With a discovered problem: users forget to open the app
- With a developer simply deciding to write some interesting new code first
- With the choice of which cloud provider to host the whole feature on
- With writing the automated tests before anyone knew what to build
Why was reminders designed to depend on a generic "notifier" abstraction?
- So email or push can slot in later without changing the reminder code
- So the finished program would run noticeably faster for all of its users
- So the team could skip writing any automated tests for the feature at all
- So the change could be merged without any pull request or review step
How was reminders released to users?
- Behind a feature flag to a small canary first, then widened to everyone
- Switched on for every single user all at once the moment it was built
- Released only after every single possible bug had been fully eliminated
- Quietly left switched off forever so no users ever actually received it
When reminders fired late in production, how did the team respond?
- On-call mitigated with the flag, and a blameless postmortem fixed the cause
- They found out whoever wrote the code and held that one person responsible
- They cancelled the whole reminders feature entirely after the first incident
- They simply ignored it and hoped the problem would resolve on its own
What is the big lesson of following one feature through every phase?
- The phases connect into one continuous craft, each step setting up the next
- That the coding part is really the only step that genuinely matters at all
- That each phase is a totally separate silo with nothing to do with the others
You got correct