Scaling any architecture demands constraints, contracts, and conviction… not just consensus in a deck of slides.
The Vibes-and-Slides Trap
Architecture can happen by accident. A diagram gets nodded at, a teams meeting closes the loop, and a “direction” is set. Or so it seems. That’s fine for the brainstorming phase. It is not fine for the system you’ll be running in production for the next five years. This is especially true when you’ll be running not one, but thousands of instances of the system.
Architecture decisions echo. They echo for many years… through every team member that joins, every app that ships, every incident that wakes someone up at 2 AM. Once those echoes start, you will pay the price of a “vibes and slides” approach.
What does hold up over years? What can you do? We have a few ideas.
Have an Opinion. Or Borrow One.
One thing that holds up that meetings and slides can’t produce is opinions, expressed as constraints.
At scale, neutrality is a fantasy. Any platform team that has tried to support every pattern, every primitive, every “well, it depends” knows that, eventually, you support none of them well. Instead, you end up with a collection of half-implemented and leaky abstractions and a backlog of conflicts no one is confident they can resolve. Even Claude.
This is a risky place to live. Changes may break unexpected technical things. Not changing may break business things.
But there are better options…
- Roll your own opinions. Decide explicitly what good looks like in your environment. Write it down. Defend it. Hold to it over the long haul. Teach new team members not just what but why.
- Adopt an opinionated distribution. Someone else has already done the hard work of resolving conflicts. Inherit their taste and spend your energy on the parts that are actually unique to you, such as niche shared services and of course, business applications.
In either case, the platform now becomes an opinionated layer that manages conflicts while actively supporting business goals, not a buffet that pushes conflict navigation back onto application teams. In reality, the moment that every application gets to invent its own pattern is the moment the platform stops being a platform.
Tight Contracts, Fewer Levers
The way the opinions we are discussing get “teeth” is through contracts. Tight contracts.
A good contract will limit the levers an application team can pull, and that’s the point. Less surface area means fewer ways to get it wrong, fewer one-off escalations, and fewer multi-year echoes of someone’s novel approach to a problem. Novel is, of course, wonderful in the application implementation, but not so in its demands for needs from the underlying platform. In short, aim for fewer primitives available by default, with future accommodations granted deliberately where it actually creates value.
This sounds restrictive. And it is. Teams trade some local autonomy for a platform that doesn’t collapse under its own variance, and a security and operations posture that doesn’t require hero culture to function and scale. Telling people “not this way” is one of the most challenging parts of being an architect (we all want to be helpful, right?), but it is also one of the most important.
At the same time, keep in mind Hyrum’s Law.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
Regardless of what you write down, the production system’s contract is the real contract your users will adhere to.
Contracts Need a Process Behind Them
A contract isn’t just a technical artifact… it governs an ongoing relationship. That relationship needs some degree of structure. The larger the number of humans working within the problem space, the more useful this becomes. Without it, we often see devolution into backchannel discussions and meeting churn over questions like…
- “Why did we do this?”
- “Why can’t we use that?”
- “It would really help us if you could enable X.”
Architecture Decision Records (ADRs) are the how. ADRs capture what you decided and why. These are especially important so that future humans who are not currently working on the project understand the constraints that have been imposed and don’t immediately change them to please a customer.
This is nothing new, but something we find extremely important when we think about engineering platforms that are intended to be durable over long periods of time.
Start Closed, Open Incrementally
The instinct on a new platform is often to start permissive and tighten things up later. You’ve never done this with an IAM role, have you? As you likely know, this almost never works in practice. What gets shipped quickly becomes load-bearing.
Instead, start closed. Open up specific levers for developers when there’s a real, articulated need, and then document why when you do. Future operators (and future you) will thank you for the trail of reasoning when they’re trying to figure out why things are the way they are.
Moving Beyond the Vibes and Slides
The hardest thing about platform architecture isn’t conjuring a “do everything” design and whiteboarding a diagram; it’s having the conviction to encode that design as constraints that people must operate within and balancing those decisions with a useful and enjoyable developer experience. This is hard work. And for truly useful platforms, this legacy of constraint must be durable over time.
Vibes are great. They get everyone excited about what could be. Slides get you through some presentations to get buy-in. Vibes and slides are cheap. Thoughtful opinions, codified in contracts and implemented in constraints, are what hold up after years.
Go beyond the vibes and slides.
The Edge Monsters: Jim Beyers, Colin Breck, Brian Chambers, Tilly Gilbert, Michael Henry, Michael Maxey, Chris Milliet, Erik Nordmark, Joe Pearson, Jim Teal, & Dillon TenBrink.
Want to go deeper? Join the Edge Monsters community.
Be sure to subscribe to updates and follow us on LinkedIn.
