Backbone
Developer infrastructure that never ships
Every project I've built in the last two years started the same way: reinventing security, reinventing theming, reinventing the same patterns I'd already solved somewhere else. That's a terrible way to work. Backbone exists so I stop doing that.
It's not a product. It never ships. It's the shared foundation — a Swift package, a research library, and a set of engineering standards — that every project inherits from. Write the hard things once. Enforce quality everywhere. Never start from scratch.
BackboneKit
The core of it is a Swift package called BackboneKit. One import gives you:
Security — AES-256-GCM encryption with PBKDF2-HMAC-SHA512 key derivation. Secure Enclave for hardware-backed keys. HPKE for asymmetric operations. A versioned encrypted package format that's ready for post-quantum migration when the time comes. All of it targeting FIPS 140-3. Not because I need government certification for personal projects — because if you're going to build security infrastructure, build it to a real standard or don't bother.
Theme — Give it a hue, get a full color palette. AppTheme is @Observable and propagates through SwiftUI's environment. Works on macOS, iOS, and watchOS without platform-specific hacks.
Core — Backbone.configure() bootstraps the app. KeychainService wraps the macOS Keychain with biometric unlock. Structured logging via os.Logger because print() is never acceptable.
41 tests across all modules. Zero external dependencies. Apple frameworks only.
The Research Library
37 documents, organized by domain. Every one exists because someone — usually me and Claude — spent real time learning something the hard way.
The rule is simple: if it wasn't obvious, write it down. Framework gotchas, API limitations, patterns that only work in specific conditions, design decisions with tradeoffs that aren't apparent until you've tried both sides. The kind of knowledge that evaporates between sessions if you don't capture it.
Topics span Apple platform patterns, Claude API integration, Node.js service architecture, and the product philosophy work that came out of Keystone's failure. When I start a new feature, the first step is always: check Research. Someone probably already paid the token cost for this lesson.
Engineering Standards
The root CLAUDE.md file is inherited by every project. Non-negotiable rules:
- Keychain for secrets. Never plaintext, never UserDefaults, never hardcoded.
- Swift views can't exceed 300 lines. Node routes can't exceed 100. Hit the limit? Refactor before adding features.
- Zero lint warnings. No unused dependencies. No phantom completions where something's marked "done" but has stub logic.
- Every session starts and ends with tests passing.
These aren't aspirational. They're enforced. I've been burned enough times by "we'll clean it up later" to know that later never comes.
Why This Matters
Without Backbone, SONET would have spent its first month rebuilding encryption primitives. Order Tracker would have invented its own validation patterns. Every project would be a silo.
With it, a new project gets FIPS-compliant security, a tested theme system, 37 documents of prior art, and engineering standards that prevent the kind of drift that turns codebases into messes. That's compound interest — not the flashy kind, but the kind that keeps you from going bankrupt.
What's the thing you keep rebuilding from scratch that you should have turned into infrastructure a long time ago?