There is a pattern we see on almost every enterprise software engagement we inherit from a previous vendor: the architecture was chosen for the wrong reasons. Not because the team was incompetent — usually they were not — but because the wrong question was asked at the start.
The Wrong Question
Most teams ask: "What is the best technology for this problem?" The right question is: "What technology can this organization successfully operate at scale for the next five years?"
These are very different questions. The first optimizes for engineering elegance. The second optimizes for organizational reality.
Our Decision Framework
Before we recommend any architecture, we run through four gates:
- Operational fit — Does the client have (or can they hire) engineers who can run this in production?
- Failure mode analysis — When this goes wrong at 2am, how bad is it, and who fixes it?
- Migration cost — If we need to change this in three years, how painful is it?
- Vendor dependency — Are we locking the client into a platform they cannot exit without a full rewrite?
The Boring Choice
Nine times out of ten, the answer that passes all four gates is the boring one. A monolith deployed on managed infrastructure instead of a microservices mesh. A PostgreSQL database instead of a distributed NoSQL cluster. A Next.js app instead of a custom SPA with a bespoke API layer.
Boring is not a failure of imagination. Boring is what keeps the lights on when the original team moves on.
When Complexity Is Justified
There are cases where complexity earns its keep. Real-time systems with sub-100ms latency requirements. Multi-tenant platforms serving thousands of isolated organizations. Event-driven workflows where eventual consistency is a genuine product requirement, not a convenience.
The key word is "requirement." Not "it would be cool" or "it will scale better eventually."
// Example: explicit trade-off comment in architecture decision record
// DECISION: PostgreSQL over DynamoDB
// REASON: Team has zero DynamoDB operational experience.
// Read patterns are relational. No need for global tables.
// Migration cost from DynamoDB to Postgres if wrong: high.
// Migration cost from Postgres to DynamoDB if wrong: moderate.
How We Document This
We write Architecture Decision Records (ADRs) for every meaningful technical choice. Each ADR has a status, the context, the decision, the consequences, and the alternatives we considered. When the client asks in year two why we made a choice, we have a document — not a story.