Notes from the Build: Data Modeling for Systems That Outlive Their First Version

Every system's most important decisions get made early, quietly, and usually before anyone in the room fully understands their consequences. Not the decisions about the interface, or which framework to use, or how the first version should look — those get revisited constantly, and reasonably so. The decisions that are hardest to undo are the ones buried in the data model: what an entity is, what it's allowed to relate to, what gets treated as immutable history versus mutable state.

This is a note on how we think about that layer, because it's the layer where the discipline of building for permanence either holds or quietly fails.

Model the domain, not the first screen

The most common mistake in early system design is letting the first interface dictate the data model underneath it. It's an understandable mistake — the interface is what's visible, what stakeholders react to, what gets iterated on in front of an audience. But a data model shaped around one screen's needs tends to break the moment a second, differently-shaped use case arrives.

The alternative is slower and less visually rewarding: model the actual domain first — the entities, the relationships, the invariants that must hold regardless of which screen is asking — and let interfaces be views onto that model, rather than the model being a reflection of one interface's requirements. This is the same principle behind designing permissions as architecture rather than a settings screen.

Treat history as a first-class citizen

A system that only stores current state answers the question "what is true right now" and nothing else. The moment someone asks "what was true last quarter" or "when did this change and why," a current-state-only model has nothing to offer but a shrug. Designing for permanence means treating change itself as data worth keeping — not as an afterthought bolted on when an audit trail becomes urgent, but as a structural decision made from the first schema.

"A system that can't tell you what used to be true isn't a record. It's a snapshot that happens to update."

Design relationships for entities that don't exist yet

The hardest part of early data modeling is resisting the temptation to model only what's known today. A permissions structure built for the departments a company has now will need to be rebuilt the moment a new department arrives with a shape nobody anticipated. The discipline is to model relationships generally enough to absorb entities that haven't been invented yet, without over-abstracting into something so generic it fails to constrain anything meaningfully — the same balance that determines whether a system counts as infrastructure rather than an instance.

That balance — general enough to extend, specific enough to be useful — is not a formula. It's a judgment call made repeatedly, and it's the single highest-leverage set of decisions in any system's early life.

Why this is worth writing down

These aren't abstract principles. They're the difference between a system that needs a costly re-architecture at year three and one that simply keeps absorbing new requirements without needing to be rebuilt. Getting the data model right doesn't guarantee a system survives a decade. Getting it wrong guarantees it won't.

Talk to Regent about building systems meant to last

Related Reading

• Notes from the Build: Permissions as Architecture, Not an Afterthought
• On Permanence
• Infrastructure, Not Instances