Two systems that depend on each other agree on a contract before they exchange a single byte: what endpoints exist, what data goes in, what comes back, what happens when something breaks. Neither system trusts the other to just figure it out. The contract exists because trust is not a substitute for specification.
Two people meet, decide they like each other, and skip that step entirely.
A contract like that can be as small as this:
POST /orders
Requires: { customer_id, item_id, quantity }
Returns: { order_id, status, estimated_delivery }
On failure: { error_code, message }
Four lines settle every possible disagreement in advance: what you’re allowed to ask for, what you’ll get back, what happens when it goes wrong. Neither system finds any of that out by accident, mid-transaction, at the worst possible time.
Companies operate the same way. Before money or work moves between two organizations, someone drafts a document defining scope, deliverables, timelines, and what happens on breach. Nobody in a boardroom says “let’s just see how it goes.” Yet two people will move in together, raise a child, or become business partners on a conversation and a feeling.
Why does the relationship with the highest technical stakes get the most rigor, and the one with the highest personal stakes gets none?
I don’t have one clean answer. I have a few ways of looking at it, and they pull in different directions. Worth sitting with each on its own.
The contract we pretend doesn’t exist
Human relationships are not actually contract-free, though. They run on contracts constantly, just unversioned ones. Nobody wrote them down, nobody reviewed them together, and both parties are quietly enforcing terms the other person never agreed to in explicit language.
Most relationship conflict, looked at closely, is a contract dispute. One person assumed weekends were for family, the other assumed weekends were flexible. One person assumed “we’ll split this evenly” meant fifty-fifty on money, the other meant fifty-fifty on effort. Nobody breached anything on purpose. They were operating against different specifications of the same interface, and neither side knew a mismatch existed until the call failed.
So the API analogy does not reveal an absence. It reveals a failure mode: implicit contracts, drafted separately by each party, never diffed against each other.
It’s the contract we signed with the country we were born into, one we never read, never negotiated, and in most cases didn’t know existed until years later. Break a law and you go to jail; the enforcement clause was always there, written into a system you were enrolled in before you could speak. Nobody handed you the terms at birth. You inherited them the way a piece of software inherits a dependency it never asked for, and you’re bound by them regardless.
Where we already do this, and where we refuse to
We already formalize some relationships. Marriage carries a license. Business partnerships get an operating agreement. Employment comes with an offer letter naming compensation, scope, and terms of exit. These are the relationships with legal or financial exposure, and we treat them accordingly.
But the relationships with the highest emotional exposure, first friendships, new romantic partners, the early months of raising a child together, stay entirely undocumented. We reserve rigor for money and leave feeling to chance. That seems backward, or at least worth questioning, given that emotional breach tends to do more lasting damage than financial breach.
Why we resist naming terms
The honest answer is that naming terms feels like an accusation. Saying “let’s define what we each expect here” to someone new sounds like you’re preparing for a lawsuit, not a relationship. It signals distrust in a moment meant to signal the opposite.
There’s also a story we tell ourselves, that real connection shouldn’t need scaffolding, that writing it down makes it less real. I understand the instinct even if I don’t fully buy it. Engineers know it’s wrong in their own domain. Systems that “just trust each other” without a contract are the ones that fail silently, in production, at the worst possible time. We don’t extend that lesson to ourselves.
I don’t think the answer is a literal contract for every relationship. That cure is worse than the disease. There’s a middle ground, though.
A lighter version worth trying
The best API contracts are not frozen at version one. They’re versioned: both sides know what changed, when, and why. A breaking change gets negotiated before it ships, not discovered after something crashes. That’s the pattern worth borrowing: the discipline, not the document.
The application is simpler than it sounds. Most relationship friction doesn’t come from bad intentions; it comes from two people who never named what they were actually optimizing for (time, effort, attention, presence) and left the other person to guess. Naming that early, even loosely, isn’t a negotiation. It’s just making the interface visible. And when expectations collide, which they will, the software mindset offers a more useful question than “who’s at fault”: it asks what changed in the spec. That reframe alone defuses most of the conflict before it escalates. The harder discipline is revisiting. People change, and they’re supposed to. A contract that never gets renegotiated eventually stops matching the people running it, and neither side notices until something breaks.
This is probably also why some friendships fade and others don’t. A friendship ending because two people grew apart isn’t a failure. That’s just a contract nobody renewed, both sides quietly letting it expire rather than forcing it. The ones that last decades tend to involve people who kept renegotiating without ever calling it that, adjusting how often they talk, what they need, where the other person is in life. The ones that end badly are usually the ones where nobody updated anything, and both people kept running the original terms long after they stopped fitting.
Nobody’s job to hand you the terms
Here’s the part of the analogy that stops being comfortable. The fine print on being human doesn’t arrive in an onboarding email. Nobody sits you down at eighteen, or thirty, or fifty, and hands you a document titled Terms of Being a Person. You’re expected to write your own draft of it, revision by revision, using whatever inspiration, experience, knowledge, and wisdom you manage to gather along the way. We tend to call that process growing up, though it never really ships a final version. Most people are still editing the draft well into their fifties and sixties, just at a slower cadence.
I don’t think that’s a gap in the system. It’s the honest answer to the question this whole piece keeps circling. It was never anyone else’s job to show you what being human means. Finding it was always yours, and it stays yours, through the people you meet, the mistakes you survive, the books that catch you at the right moment. The one clause you don’t get to revise on your own terms is the one from earlier, the contract with the country you were born into. You can interpret, question, and rewrite almost everything about how you choose to live. That one, you just have to honor.
None of this requires paperwork. It requires treating the start of a relationship the way a good engineer treats the start of an integration: not with suspicion, but with the humility to admit that two people who haven’t talked about what they expect are running different versions of the same agreement.
So take your pick of what to sit with. That most conflict is a spec mismatch, not a betrayal. That the one contract you never chose is the one you’re least free to renegotiate. That naming expectations early feels colder than it actually is. That some things fade not because anyone failed, but because nobody renewed the terms. That finding out what being human means was never going to be handed to you, and it isn’t supposed to be.
I don’t think these fit together into one lesson, and I’m not sure they need to. They’re just what the analogy kept surfacing, one layer at a time, the longer I sat with it.