The Shortcut To Better Engineering Decisions
Better Decisions Start With a Simple Question: What Problem Are We Actually Solving?
A few years back, Uber engineers joked that their backend looked like the Death Star (you can look up the diagram later, it’s wild). Thousands of microservices, tangled lines everywhere, nobody really sure where the boundaries began or ended. Brilliant people, world-class infra, everything… except clarity.
It’s a great reminder. Most engineering decisions go sideways not because people are bad engineers, but because the team never agreed on the actual boundaries of the problem.
Good engineers ask: “What should we use?”
Great engineers ask: “What are we solving for?”
And founders? We ask a slightly different questions: “Will this actually make users happier?”
Because if the answer is “not really”, then why are we even talking about Redis cluster topologies at 10am?
Why This Matters
Most engineering rabbit holes start with curiosity + ambition + lack of constraints.
Without boundaries, everything feels important:
Should we introduce event-driven architecture?
Should we migrate to Rust for performance?
Should we containerize every single thing?
The problem is… those aren’t business questions.
The real questions are:
Does the user’s life change if we solve this perfectly?
What breaks if we don’t solve it at all?
What’s the minimum structure we need to ship of value?
Are we solving a real bottleneck or just building because it feels clean?
This is where boundaries help. Boundaries create clarity, and clarity prevents smart engineers from overbuilding.
A Personal Lesson I’m still Embarrassed About
At one of my previous startup, we made this mistake hard.
We were early-stage. No scale. No heavy traffic. Barely enough users to call it “load”.
And yet, one of my senior engineers kept proposing a full-blown architecture setup: Docker everything, message queues, caching layers, full orchestration, rewrite the whole codebase into a more performant language. All before we even had users that needed any of that.
We also kept building stuff from scratch, things that had perfectly good, market-proven solutions. We burned weeks building custom components we could’ve replaced with a SaaS tool or an open-source library.
And to be fair, we’re seeing this everywhere. I learned this lesson the hard way too.
Why?
Because we didn’t start with boundaries. We didn’t ask the one simple question:
“What’s the minimum structure we need right now to ship something users actually care about?”
When you don’t define boundaries, every technical idea feels legitimate.
With boundaries, 80% of the ideas automatically fall away.
What Boundaries Look Like in Real Life
Before choosing tools, frameworks, or architectures, define constraints like:
Timeline: “We need something working in 2 weeks.”
User impact: “This feature must reduce a task from 10 mins to 2 mins.”
Scale: “We expect 50 users, not 5 million.”
Team reality: “We have one backend engineer, not seven.”
Risk tolerance: “If it breaks, the blast radius is small.”
Once you frame the problem like this, engineering becomes way simpler.
Suddenly, the question isn’t “Should we use Kafka?”
It becomes “Will Kafka actually make a user happier this month?” (usually the answer is no)
The Mental Shift that Makes Engineering 10x Easier
Define the boundaries —> decide the approach —> pick the tools.
Most teams accidentally reverse this.
Great engineering isn’t about knowing every modern tool. It’s about knowing which part of the system actually matters right now.
When you approach decisions this way, you don’t just build faster, you build saner.
You stay focused on the part that makes users say, “Oh wow, this actually helps”.
Not the part that makes engineer say, “Oh wow, this architecture is beautiful.”
If You Take One Thing Away from This Post
Before you choose what to build, ask:
“What are we solving for, and what are the boundaries?”
Set constraints upfront. Then build the simplest thing that hits those constraints. Your engineers will move faster, your users will be happier. And your future-self will thank you for not rewriting everything in Rust at 100 users.