Engineering
Patterns extracted from one real production codebase, each written as a self-contained tutorial on a neutral example domain — general enough to apply in any Django project, and to publish alongside the apps as they are open-sourced. Read in order: part 1 is the mental model the rest build on.
Part 1 · One domain core, many thin transports
the operations pattern — A domain core that owns authorization, an operation catalogue with no private APIs, two entry points (perform / perform_json), gates, effects and before/after history — one write path serving HTML, a JSON API, OpenAPI, LLM tools and MCP.
Part 2 · A real MCP server, and the OAuth that guards it
remote MCP over OAuth — Serving the operation catalogue over Streamable HTTP; the full OAuth 2.1 dance (discovery, DCR, PKCE); consent as a durable, editable grant; and the attenuation stack that keeps it honest.
Part 3 · Testing a system you can't afford to run for real
the five-layer hexagon — Unit / acceptance / integration / boot / smoke; a real browser on the real WSGI path; fast keepdb + serialized-baseline databases; contracts locked by tests; and driving the MCP server with the official SDK + a real browser.
Part 4 · The chat agent: a backend-neutral transcript
chat and tools engine — One transcript model, two LLM providers behind one adapter, an in-memory tool catalogue, a synchronous streamed loop on gevent, effects to the UI, and a denial-of-wallet budget.
Part 5 · Booting without cloud-init
the systemd boot graph — Boot as an ordered systemd unit graph that restores the database before the app starts; fail-closed config; restore-or-init; and a box that heals itself.
Part 6 · Infrastructure as code, and deploy on merge
fast recovery over high availability — The recover-fast-not-replicate bet; five CloudFormation stacks split by lifecycle; the wheelhouse and the four buckets; one admin command (platform.sh) and OIDC-wired CI (github.sh); deploy on merge / on tag; test output baked into the release.
Part 7 · Cost and abuse control
three independent layers — A per-user denial-of-wallet budget in the app, a token kill-switch in the cloud the app cannot bypass, and a fail-open egress cap on the box — plus knowing which way each control should fail.
Part 8 · Fail-closed configuration
refuse to start rather than start wrong — Every required setting read with no default; no .env; three sources and one reader; a separate tuning() for optional values; and a sentinel so "explicitly off" survives a store that cannot hold an empty string.
Part 9 · htmx without the SPA tax
rich UI, no build step — Two swap strategies per shell (hx-boost vs targeted opt-in); views that always return whole pages; OOB flash messages on partial swaps; and live updates from the effects stream — no client framework, no JSON API for the UI.
Part 10 · Eager, pluggable rendering
the media pipeline — Render uploads once into bases + a sprite sheet; pure transforms that cannot drift; one pluggable backend (inline / subprocess / serverless); and the queue-function-HMAC-callback production path.
Part 11 · One account widget, every shell
define it once — A single top-right account control included by the marketing, auth and app shells; auth state and role links inside the component; behaviour that survives htmx swaps via idempotent binding; accessibility done once.
Part 12 · Default-deny, everywhere
one principle, four layers — The security posture as a single idea: login required by default, a deny-by-default firewall (inbound and outbound), no standing SSH, and fail-closed config — so forgetting fails safe.
Part 13 · Automatic HTTPS on a disposable box
certs that survive replacement — Auto-certificates whose state lives in a bucket so a replacement box reuses them, plus a staging-by-default fallback that makes it impossible to burn the certificate authority's rate limit while iterating.
Part 14 · Backups you've actually restored
restore is the boot path — Continuous backups + WAL to object storage for a ~60s recovery point; making restore-or-init the boot path so recovery runs on every replacement; idempotent bootstrap; and drills that prove the nasty cases.
Part 15 · Channel-pluggable notifications
one notify(), done right — One notify() entry point behind which channels are pluggable; transactional-vs-activity categories; and a one-click unsubscribe that a link-scanner's GET cannot trigger.
Part 16 · A living component gallery
a design system that cannot drift — Reusable UI as template partials real pages compose; a staff-only gallery that includes the very same partials in their states, so the showcase shares source with production and cannot drift; plus a routes hub.
Part 17 · Invitations and permissions: one membership table
membership as one row — The owner is a membership, an invitation is a not-yet-accepted membership, and what a member may do is a set of named operations they hold — not a rank — plus scoped reads and a single-use, expiring, idempotent invite that carries a set.
Part 17 · One deploy layer, three platforms
onebox — cattle and pets, one payload — N services per host from one manifest; template systemd units; one shared payload run verbatim by the AMI bake, the VPS/Pi provisioner and the boot harness; offline venvs from a hash-pinned wheelhouse; artifacts by bucket or by SSH forced-command stream — no cloud credentials on the pets.
Part 18 · Reactive islands: Preact signals without the build step
the one rung above htmx — Where htmx strains — dense real-time client state — drop a scoped reactive island: vendored @preact/signals-core + tiny bind.js/h.js helpers bound to server-rendered DOM, no build step, one component not the whole app.
Part 18 · Scope-less: consents, not scopes
the v3 token model — Why the api:read/api:write scopes were deleted: the per-tenant policy on a consent already answered the real question precisely. One token.require() for browser sessions, bearers and the in-app assistant (a consent with client=NULL); instant revocation; a consent screen with no theatre.