The capabilities-demo generator

This is a system, not a project. The problem it solves: a capabilities catalogue (95 production features across 38 client organizations) needs to be shown to prospects, tailored per RFP, and kept current by people who don't write code. Hand-maintaining an HTML demo fails on every one of those counts.

When the intro says “I build systems that write it for me”, this is the literal, pre-existing proof: it is how I worked before agents entered the picture.

A three-stage pipeline where humans only ever touch stage one:

• —An Excel workbook as the single source of truth: feature rows with Include flags, a client master list, the tech stack, and domain tagging
• —A Python generator that reads the workbook and emits the entire demo
• —A single self-contained portable HTML file: screenshots base64-inlined (with caching so regeneration stays fast), lightboxes, domain filters that appear automatically based on what's tagged, public/private chips, and client cross-linking
• —Per-RFP versions by toggling Include flags: flip rows off in Excel, regenerate, send the trimmed demo

The senior part is the shape of the system, not any one script:

• —Choosing Excel as the interface: the one config format non-technical colleagues already know, which is what makes the system maintainable after I walk away
• —Designing the workbook schema so one source of truth drives features, clients, stack, and domain filters without drift between them
• —Making the output a single portable file (no server, no dependencies, no “does the demo work on their network”), which is a deliberate distribution decision, not a limitation
• —Base64 inlining with caching: the boring engineering that keeps a screenshot-heavy single-file build practical to regenerate

The generator itself is the point of comparison: it's the systems-over-typing philosophy implemented in plain Python, before agents. It also became the substrate for the next step: routine changes to this system are now executed by Claude Code as written tasks with a provided script, a verification step, and an explicit stop condition; /systems walks through how that pattern works.