Module 11: Continuous Improvement

Anchor outcome 14 months post-launch, 0 regressions from refactor work. 3 structured post-mortems produced 7 prevention measures — 6 of 7 would-be repeat incidents caught before production. Billing disputes: zero in 10 months of monthly retainer.

Most of what goes wrong after launch isn’t bad code — it’s bad process. Spec docs that nobody updates. Incidents that repeat because the first one produced “be more careful” as its lesson. Refactors that break working features. Billing that makes the client feel like they’re paying into a black box. This module covers the discipline layer that prevents all four.

The 4 lessons

Lesson 11.1

Spec Docs That Survive 6 Months

The current-state / change-log structure that keeps docs useful, the 5 update triggers, why specs live in the repository not in Notion, and the onboarding test (new developer, 25 minutes, 3 questions).

Lesson 11.2

Refactor vs Ship Decisions

The 4-question decision framework, REFACTOR.md for tracking deferred items with review dates, the lead query builder consolidation as a worked example, and when refactoring IS the right call.

Lesson 11.3

Failure-Mode Reviews

The post-mortem template that produces specific prevention measures (not “be more careful”), the prevention measure quality standard, and the “what we won’t change” section that keeps scope tight.

Lesson 11.4

Billing Transparency

The monthly work log format that connects work to outcomes (not hours to tasks), the numbers section that ties effort to results, and why the owner started forwarding sections of the log to the sales team.