12 patterns · 128 working examples
Every record's ID says what it is (usr_, acc_, …) — so every log line, link, and support ticket explains itself.
12 patterns (11 Pro · 1 Agency) · 128 working examples
These aren't chapter titles — each one is an enforced rule your AI builds against. And the patterns don't just teach the shape: the working examples are real code that lands in your project.
The intake questions a new project needs answered before scaffolding can start
Why the browser should never be allowed to talk to the database directly
Picking one ID format so URLs, public IDs, and foreign keys never disagree
Keeping tenant-scoped URLs from breaking when routes change
Keeping app types and the database schema from silently drifting apart
Why config like statuses and roles should never live in two places
Keeping local dev, CI, and production database state from drifting apart
Keeping server, web, and mobile from each hand-rolling their own data access
Stopping a second React copy from silently sneaking into the monorepo
Declaring an entity once instead of wiring search, AI tools, and routes separately
Where a new project's starting skeleton should actually come from
Shipping a breaking API change without ever actually breaking a caller
Every new part of the app invents its own ID style; within months there are three, and nothing lines up with the database.