I sat through a design review for one of my apps recently. The app itself is simple: a FastApi endpoint that searches a FAISS index of Jira and Zendesk tickets, and another endpoint that summarizes results using a locally hosted Ollama model. That’s it. It solves a clear, narrow problem for our L3 support engineers.
Within five minutes, the suggestions started rolling in: “We should build our own MCP server,” “add webhooks,” “integrate with tool-chains,” and more. All interesting ideas, but they ignored four simple truths I wish more architects considered.
First, team size: This app was built by a senior and a junior engineer. We don’t have a 20-person platform team to maintain bespoke infrastructure. The solution should respect the people actually building and running it.
Second, cost and velocity: Every additional component, whether it is an MCP server, a queue, or an integration, adds not just development time but also ongoing maintenance and hosting costs. By contrast, our app is cheap to run, easy to read, and quick to modify. If someone new joins the team, they can get up to speed in a day. If a change is needed, it takes hours rather than weeks. That speed of iteration is its own kind of cost saving.
Third, Occam’s razor: The simplest solution is often the right one. If you can solve the problem directly without extra layers of ceremony, why complicate it? Complexity creates friction: harder onboarding, slower changes, and more fragile systems. Simplicity is not about being naive, it is about deliberately choosing the most straightforward design that meets the need. In practice, that often means writing the fewest moving parts possible and resisting the urge to design for scenarios that may never arrive.
Fourth, maintenance horizon: A system is only as good as the people who can keep it running. In six months or a year, will new engineers still be able to understand and evolve it? Simpler systems spread knowledge more evenly, lower the risk if someone leaves, and make replacement or handover far easier. That stability is a hidden but very real advantage.
Of course, making something truly enterprise grade is another ballgame. It requires more layers of complexity: compliance, governance, monitoring, integration, and security. But even in those cases, simpler solutions tend to win. When systems are easier to understand and modify, they remain more adaptable even as complexity grows around them.
History shows this pattern again and again: technologies that seemed indispensable just a couple of years back often get leapfrogged by simpler, smarter tools. With LLMs, entire categories of internal apps are already being replaced by automated workflows.
The cultural challenge: In many organizations, complexity gets celebrated because it looks smart and sophisticated. But the real craft lies in designing something simple enough to deliver value immediately and flexible enough to adapt when the ground shifts. We should reward that kind of clarity more often.
A Simplicity-First Architecture Checklist
When reviewing or proposing a solution, ask these questions before adding layers of complexity:
- Team size: How many engineers will build and maintain this? Can new team members understand the system in under a week?
- Delivery time: What is the expected timeline for delivering value? Does the design allow for quick changes and fast iteration?
- Cost considerations: What are the hosting, licensing, and ongoing maintenance costs? Does the complexity increase long-term cost of ownership?
- Maintenance horizon: In 6–18 months, will this still be easy to support? What happens if the original developers move on?
- Enterprise requirements: Are compliance, governance, monitoring, and security required from day one? If so, can we still keep the design as simple as possible within those constraints?
- User need first: Does the solution directly solve the current problem for its users? Are we building for real requirements or hypothetical future scenarios?
- Market change readiness: If the market shifts in 2–3 years, can this solution be replaced or rethought without excessive cost?
- Cultural reflection: Are we valuing simplicity, or are we rewarding complexity because it looks more impressive?
Simplicity is not laziness. Sometimes, it is the most strategic choice you can make.
Leave a Reply