Reuse the Platform's Primitives Instead of Reinventing Them

When I evaluate a tool — or decide whether to build one — a strong signal of quality is whether it wraps the platform’s own primitives or tries to reinvent them. The best infrastructure tools I’ve used are surprisingly thin: they lean on capabilities the underlying system already provides and add orchestration on top, rather than re-implementing hard guarantees from scratch. Reinventing a primitive that the platform already gives you for free is how you end up owning a pile of subtle correctness bugs the platform had already solved.

The tell: thin wrapper or heroic rewrite?

Assessing a backup tool for a distributed database recently, the thing that sold me wasn’t a feature list — it was how it worked. Instead of inventing its own way to get a consistent point-in-time copy, it called the database’s native snapshot command. Instead of inventing change tracking, it exploited a property the database already had: its on-disk files are immutable once written. The tool was mostly orchestration — snapshot, upload, track topology — wrapped around primitives the platform supplied. That thinness is a feature, not a shortcut.

The best tools are mostly glue. They orchestrate primitives the platform already guarantees instead of re-deriving the guarantees themselves.

Why wrapping wins

Native primitives carry guarantees that are genuinely hard to reproduce, and free-riding on them buys you correctness and efficiency you’d otherwise sweat for:

• Correctness you didn’t have to prove. A database’s own snapshot is consistent by design — the engine knows how to freeze its state safely. Reinvent that from outside and you’re reasoning about consistency the hard way, with more ways to be subtly wrong.
• Efficiency that falls out of the design. Because the database’s files are immutable, a snapshot can be a near-instant hardlink rather than a copy, and incremental backups only need to ship the files that are genuinely new. The tool gets cheap snapshots and cheap differentials for free by understanding a primitive, not by building dedup machinery.
• Less surface to maintain. Every guarantee you wrap is one you don’t own. The platform’s maintainers keep it correct across versions; you keep the orchestration thin.

The version that reinvents these — hand-rolled copy scripts, custom change detection, bespoke consistency logic — is doing more work to get a worse, more fragile result.

Know the primitives before you build

This generalizes into a habit: before building anything that smells like a solved infrastructure problem — backup, replication, locking, change capture, snapshotting — find out what the platform already exposes. The good primitives are often hiding in plain sight: atomic snapshots, immutable storage, copy-on-write filesystems, transactional guarantees, event logs. The question to ask first isn’t “how do I build this?” but “what does the system underneath me already guarantee that I can stand on?”

I’d reinvented things before that the platform already did better, purely because I didn’t go looking. The few minutes spent learning what’s available routinely save days of building a worse version of it.

When reinventing is actually justified

To be fair: sometimes you do build the primitive yourself — when the platform genuinely lacks it, when its version doesn’t fit your constraints, or when the wrapper layer can’t reach what you need. That’s legitimate. The point isn’t “never build,” it’s “don’t build by default.” Reinventing a primitive should be a decision you made on purpose after confirming the platform can’t give it to you, not the path you wandered down because you never checked. And when you do build one, build it as a primitive others can wrap, the same way the platform’s is.

Build at the wrapping layer

So my default now is to assume the hard guarantee already exists somewhere beneath me and to go find it before writing a line. The leverage is enormous: thin orchestration over solid primitives is easier to write, easier to trust, and easier to maintain than a from-scratch reimplementation that has to re-earn correctness the platform already established. It’s the same spirit as querying the data without standing up the whole server and building a small local harness — use what’s already there at the right layer instead of rebuilding the world. If you’ve got a favorite platform primitive that saved you from reinventing a wheel, tell me about it.