One spine, many surfaces.
A four-person studio shouldn't be able to ship a product across desktop, web, iOS, and an AI surface in 14 weeks. The reason we can is structural — a fixed methodology we call Spine. Here's what it actually is.
Most multi-surface products fail in one specific way: translation drift. The desktop has one navigation pattern; the web has a slightly different one; iOS has a third; the AI surface uses a fourth tone of voice. Each is reasonable in isolation. Together, they feel like four products from four teams.
Spine is the methodology that prevents that. It has three parts: tokens, decisions, and audit.
Tokens — the vocabulary, not the screens.
The first instinct in a multi-surface build is to share components: the same Button on web, iOS, and desktop. This breaks immediately. iOS conventions differ from desktop conventions; forcing them to share a component creates uglier outputs everywhere.
Tokens are different. Spacing, type scale, color, motion timing, radii — these are not components. They're vocabulary. Every surface uses the same tokens, but the components built from them are surface-native. The Button on iOS looks like an iOS button; the Button on desktop looks like a desktop one. Both use the same --ink, --rule, --r-md, --t-fast.
This is what lets a single small team ship four surfaces (e.g. Tauri desktop, Next.js web, SwiftUI iOS, a RAG-AI surface) with zero color drift in audit, while each surface still feels native.
Decisions — the source of truth, not the deck.
Every product decision lives in a numbered register, not in a Figma file. A typical entry — Decision D·02: "AI is a surface, not a feature." That's the whole entry. The rationale is one paragraph; the implications cascade across all surfaces.
This matters because decisions outlive deliverables. A Figma frame from week 4 is wrong by week 8. A decision is still right, or it's been explicitly superseded with a new entry. The decision register is the single source of truth. Not the latest mock, not the Slack thread, not the meeting notes.
Audit — the ritual that keeps it honest.
Tokens and decisions both decay if you don't measure them. Two rituals keep them alive:
- Friday token audit. Every Friday, run a script that scans all surfaces for hard-coded values that should be tokens. The output is a numbered list. The list goes to zero before merge. We treat this as a standing weekly practice — it takes 30 minutes and prevents a year of drift.
- Weekly decision review. Open the register; mark which decisions changed; document why. Decisions that flipped twice in a month are usually a sign of an unresolved deeper question — those get escalated and answered, not flipped again.
Why this is structural, not stylistic.
Most "design systems" are component libraries. They reduce visual variance. They don't, by themselves, reduce conceptual variance — the deeper drift where iOS thinks the app is about phone-quick checks and desktop thinks the app is about deep analysis. Both are reasonable; both can't be true at once.
Spine forces conceptual coherence by making the decisions explicit, then deriving the tokens and components from them. The components fall out. The frame coherence falls out. The brand voice falls out. The thing being shipped is the decision register; everything else is execution.
What this lets a small team do.
- Onboard a new engineer to the iOS surface in two days, not two weeks — they read the decision register, learn the tokens, and ship.
- Replace a contractor without the next person re-litigating settled choices.
- Hand off cleanly at the end of an engagement. The decision register and token doc are deliverables.
- Re-run the methodology on the next engagement without rebuilding the whole apparatus.
What it isn't.
Spine is not a UI kit. It's not a Figma library. It's not a CSS framework. Those things exist alongside it; they don't replace it. The methodology is the part that travels between projects.
The shortest version.
One vocabulary (tokens). One source of truth (decisions). One discipline that keeps both alive (audit). The components are downstream. The brand is downstream. The product is downstream. Ship the spine first; the surfaces follow.
This is the methodology behind every Oviompt engagement. See it across six engagements, or file an intent to put it on your build.