A Thousand Ways to Do It Right
As a Tech Lead and mentor, I often start new projects by telling the team: “There are a thousand ways to do things right, but we have to choose one according to what is needed.”
I use this phrase because I’ve seen too many projects get stuck in the abstract. As developers, we love to chase the “perfect” solution or the newest tech. We debate frameworks and argue about “best practices”, but we forget to ask what the actual need is. And that “need” isn’t just a list of requirements; it’s the full context—including the budget we have and the existing knowledge our team holds.
This brings me to a second principle I follow: Time always becomes more expensive.
When I say “expensive,” I’m not just talking about money. I mean the physical and mental cost of burnout, stress, and late-night bug fixes. We have a finite amount of this “expensive” time, and it’s far better to spend it on improvements than on error fixes.
Analyzing the project from the beginning and selecting the most suitable system architecture is what makes the difference. It’s the decision that determines whether our future time is spent creating value or paying down debt.
In this first post of my Pragmatic Architect’s Playbook, we’ll apply this lens to the most fundamental choice we make: our core architecture. And we’ll start by challenging the industry’s default answer.
2. The Case for the “Boring” Monolith (When It’s the Right Choice)
Let’s apply our principle to a common scenario: a new project for a static website, a simple blog, or an internal tool with a handful of users.
The team is excited. They pitch a modern stack: a cluster of microservices in Kubernetes, a React frontend, and a message queue for good measure. It’s a “perfect” solution on paper. But we must ask: what is the need?
The need is for a system that won’t require:
Complex, real-time calculations
Medium-to-large-scale data processing
Intricate user permissions or multi-tenant sessions
Complex reporting engines
The need is for a system where scaling will be minimal or non-existent over a long period.
For this case, the “one right way” is almost always the monolith.
Why? Because building microservices here is over-engineering and an unjustifiable expense. You are spending that “expensive time” on solving problems you don’t have.
The pragmatic choice—a single codebase, a single database, a simple deployment—delivers value now. It solves the client’s actual problem, and it saves your team’s valuable time for challenges that matter. Choosing a monolith here isn’t “old-fashioned”; it’s economically sound.
3. When the Monolith Becomes the Monster
But that simple monolith rarely stays simple. It succeeds. It grows. And slowly—without a single “crisis” moment—that “economically sound” choice can become a monster.
The turning point isn’t a performance crash. It’s when the system requires too much attention. The monolith becomes the enemy when maintaining it becomes a full-time job. This is where our “expensive time” truly begins to disappear.
Symptoms are familiar to any senior developer:
Time lost in error-hunting: The team’s velocity collapses. Instead of building new features, they spend time tracking bugs or checking that changes don’t break everything.
High-risk, heavy deployments: A small change requires redeploying the entire app. Every deployment becomes a slow, stressful event.
The core-modification trap: To add new functionality, you must modify the core. Even with modularization, this consumes huge amounts of time and attention.
At this point, the pragmatic analysis must be revisited. The need has changed. The priority is no longer “shipping a product”; it’s scaling the team and the feature set. And this is where our “one right way” must evolve.
4. The Case for Microservices (When You Actually Need Them)
This is where microservice architecture becomes powerful—not because it’s “modern,” but because our needs have changed.
A microservice architecture becomes the “one right way” when your system needs:
Scalability for specific processes
Complex business logic across multiple distinct domains
Custom reporting that shouldn’t slow down user-facing workflows
Long-term feature expansion and constant evolution
By breaking the monolith into services, we solve exactly the problems we identified earlier. This approach allows teams to:
Isolate functionality: Heavy processes can scale independently.
Identify problems faster: Failures are easier to pinpoint.
Divide work across teams: Each domain evolves without interfering with others.
Reduce deployment risk: Teams ship updates rapidly without redeploying the entire system.
Microservices aren’t a trend—they are a response to evolving needs.
5. Conclusion: Your “Right Way” Is What Solves the Current Problem
The key takeaway is this: a “modern” practice is not a definitive solution.
There are indeed a thousand ways to build a system. A monolith is one. Microservices are another. Both are “right” in the correct context.
The true good practice is understanding the options available and choosing the correct one for the current problem—accepting that multiple solutions can coexist and that today’s right choice might need to change later.
This pragmatic analysis is essential because, as I always tell my teams, time always becomes more expensive.
Our job as architects and leaders is to make choices that allow our team to spend that valuable time improving, not fixing.
In Part 2 of the Pragmatic Architect’s Playbook, we’ll apply this same lens to database architecture—and explore why a so-called “bad practice” like data duplication may be your best move for performance.
Ready to build more pragmatic, scalable architecture?
If you’re exploring how to design resilient systems, evolve your architecture, or support long-term product growth, we can help you build solutions aligned with real business needs.
Contact us to discuss your next project.
