Case notes (anonymized)

Same lessons, no names, no addresses. Each note is a real shape of problem, stripped of anything that could map back to a live product. The point is the pattern, not the address.

A consumer-facing SaaS. A product where users send events and get automated actions back. The sharpest lessons here were about money and replay: store money as whole cents, and guard every incoming third-party event with a uniqueness constraint so a replayed webhook never doubles an effect (Part 7). And about the home screen: the biggest product win was removing a feature, not adding one, because the thing users actually needed was "what do I do now," not "here is your data" (Law 3 on rejected paths, and the taste that stays human, Part 11).

An internal tool. A back office used by a small operations team. The lessons were about data truth and mass change: an object whose name did not match its meaning caused a relationship to reject most of its rows until it was fixed by usage rather than by name (Law 7), and every bulk data change was proven by an invariant and a production delta, never by a re-read (Law 6).

A client app. A product built for someone else, where documentation and verification carried the most weight. The two most expensive lessons: a verification that was written down but never actually run, which quietly left files exposed for months (Law 4), and the discipline of writing every decision with its rejected alternatives so the same debate didn't reopen months later with someone who wasn't there (Law 3).