I've sat through enough technical debates to predict exactly how they'll go.
Someone suggests a framework. Another person counters with a different one (possibly me). Twenty minutes later, we're deep into performance benchmarks, bundle sizes, and whether TypeScript generics make the codebase more maintainable.
Meanwhile, the customer is still waiting for us to solve their actual problem.
And here's the uncomfortable truth: they don't care which framework we choose. They care if we solved their problem. Fast.
The Trap of Technical Perfectionism
I used to be that developer who needed every decision to be "right."
- React or Vue? Let's compare virtual DOM implementations.
- Should we refactor this prop drilling into Context? Let's debate the trade-offs for an hour.
- MongoDB or PostgreSQL? Better write a comparison matrix.
Every technical decision felt like it needed deep analysis, careful consideration, and team consensus.
And you know what happened? We shipped slowly. We over-engineered. We built things nobody asked for because we were so focused on how we built that we forgot why we were building.
The change came when I started working more closely with product and business colleagues. They taught me something I didn't learn in any coding tutorial:
Focus on now.
Not on the perfect scalable architecture for when we have a million users. Not on the most elegant solution that demonstrates our technical prowess. On shipping the MVP, iterating, and creating value for the customer.
What Product Teams Know That We Often Forget
Product managers live in a world of trade-offs. They understand something fundamental:
Done and iterating beats perfect and delayed. Every time.
They're not suggesting we write garbage code and ship it. They're suggesting we stop debating theoretical problems and start solving real ones.
Over eight years, I've learned their most valuable question: "What's the smallest thing we can build to test if this solves the problem?"
- Not: "What's the most technically impressive solution?"
- Not: "What will make our codebase look amazing in the architecture review?"
- But: "What gets us to feedback fastest?"
The Two Questions That Cut Through the Noise
When I feel a technical debate heating up (or when I'm the one heating it up), I've learned to pause and ask:
What's relevant now? Not in six months when we might have scale problems. Not when we have the budget for a rewrite. Now. Are we actually experiencing performance issues, or are we debating potential future performance issues? Do we have real data showing users need this feature, or are we building what we think they need? Is this technical debt actually blocking us, or does it just feel uncomfortable?
How can we get the most value out of the most basic implementation? This one hurts because it forces us to admit: the fancy solution probably isn't needed yet.
- Can we ship this with a simple state object before we build out Redux?
- Can we use fetch before we implement a full caching layer?
- Can we validate this idea with a prototype before we architect the perfect system?
Verify, then iterate!
Not build perfectly, then discover nobody wanted it.
A Story About Prop Drilling and Reality
Once, a developer on my team spent three days refactoring our prop drilling into an elegant Context solution.
The code was beautiful. The architecture was clean. The implementation was technically impressive.
Not a single customer noticed.
You know what they did notice? That we hadn't shipped the feature they actually requested because we were busy refactoring code that already worked.
I'm not saying that refactor was worthless. Context is often the right choice. But the timing was wrong.
We optimized for developer satisfaction instead of customer value.
And that's the trap. Technical quality feels like the responsible choice. But sometimes, it's just procrastination disguised as professionalism.
The Balance Nobody Talks About
Here's where this gets nuanced: I'm not saying ship garbage and call it an MVP.
I'm not saying ignore code quality, skip tests, or tie loose ends together and pretend it's done.
I'm saying: be mindful of how much debate you're entering before you've built anything.
There's a spectrum:
Too far left (ship garbage):
- No tests, no structure, just hack it together
- Technical debt that blocks future work
- Code so brittle that every change breaks something
Too far right (perfect or nothing):
- Debating architecture before validating the need
- Building for scale you don't have
- Refactoring working code because it "could be better"
The sweet spot (verify, then iterate):
- Build the simplest thing that solves the problem
- Ship it, get feedback, learn
- Then decide if it needs to be better
Sometimes the MVP is the answer you need. Sometimes it reveals that the whole approach was wrong and you need to pivot. Either way, you learned something real instead of debating something theoretical.
🛠️ How to Apply This
When facing a technical decision:
- Ask: "What problem are we actually solving?" Write it down. Make sure everyone agrees. If you can't articulate the customer problem clearly, stop debating solutions.
- List the simplest possible implementations. Force yourself to consider boring, basic solutions before the fancy ones.
- Estimate time to feedback. How fast can each option get you to real user validation? Weight this heavily.
- Check your motivations. Are you choosing this because it solves the customer problem, or because it's more interesting to build?
When debates get heated:
- Pause and ask: "What's relevant now?" Redirect from theoretical to actual.
- Request data. "Do we have evidence this is actually a problem?" forces the conversation to become concrete.
- Propose an experiment. "What if we tried the simple version first and measured?" Usually the answer becomes obvious fast.
- Set a decision deadline. "Let's discuss for 15 more minutes, then make a call." Prevents endless debate.
When tempted to refactor:
- Ask: "Is this blocking customer value?" If no, it probably can wait.
- Calculate opportunity cost. What could you ship instead with that time?
- Get customer feedback first. Sometimes you discover you built the wrong thing entirely, making the refactor irrelevant.
The Uncomfortable Truth
- Your customers don't care about your stack.
- They don't care if you chose Vue or React.
- They don't care if you refactored your prop drilling spaghetti into an amazing Context solution.
- They don't care about your bundle size, your performance benchmarks, or your elegant architecture.
- They care if you solved their problem.
And here's the thing that took me years to accept: this doesn't mean your technical skills don't matter. They absolutely do.
But they matter in service of customer value, not as an end in themselves.
The best engineers I know aren't the ones who write the most elegant code. They're the ones who ship the right things at the right time, balance quality with speed, and know when good enough is actually good enough.
🤔 Questions to Reflect On
- When's the last time you chose a simpler solution over a more impressive one?
- Are you debating technical decisions to solve real problems, or to demonstrate expertise?
- What would happen if you shipped your current "not quite ready" solution and iterated from there?
- How much of your technical quality focus is actually serving customers vs. serving your own standards?
🎯 The Bottom Line
Sometimes the MVP is the answer you need.
Not because it's perfect. Not because you're proud of it. But because it gets you to feedback, learning, and real customer value.
Verify, then iterate.
Everything else is just debate.
How do you balance technical quality with shipping value to customers? Share your approach in the comments—I'd love to hear how other developers navigate this tension.
If you want to dive deeper into making technical decisions that actually matter, check out my book From Hello World to Team Lead.
Photo by Fotis Fotopoulos on Unsplash
Top comments (1)
As someone still trying to enter the industry, this was a really helpful perspective.
It’s easy to get caught up thinking “I need to use the perfect stack to look employable,” when in reality the ability to ship something simple that solves a real problem probably matters more.
The point about focusing on what’s relevant now instead of worrying about future scale really clicked for me. Makes me rethink how I choose tech for my own projects too.
Appreciate this, feels like the kind of mindset shift juniors need but rarely hear.