A few years ago, I spent two weeks polishing a system design that never shipped.
At the time, I thought I was doing the “architect” thing, diagramming every edge case, accounting for every possible failure, comparing five different tech stacks. Every decision was a rabbit hole, and I kept diving in.
In hindsight, I wasn’t doing architecture. I was just stuck, chasing a design that would never feel done, trying to account for problems that hadn’t happened yet.
The irony? The project changed direction. My design, perfect or not, never mattered.
What I learned is simple: architects aren’t expected to be perfect; they’re expected to move things forward.
💡 The Myth of the Perfect Design
There’s this common belief, even among experienced developers, that the job of an architect is to come up with the best design. The one that handles everything. No regrets, no edge cases missed.
But that’s not how real systems are built.
Architects don’t chase certainty. They make decisions in motion.
A great design isn’t the one that solves every possible problem.
It’s the one that solves the right problem at the right time, within the limits you’re working in, deadlines, team bandwidth, business needs, and legacy constraints.
A “good enough” design, backed by clear reasoning and written tradeoffs, often outperforms a “perfect” one that never ships.
And you know what’s underrated?
Being able to say, “This isn’t perfect, and that’s okay.”
Because the system will change. The context will shift. The best you can do is document why you made this call now.
🔍 Why We Fall Into This Trap
This perfectionist mindset is everywhere in engineering culture:
Code reviews that nitpick instead of challenge assumptions
Blog posts showing elegant but unrealistic systems
Job interviews that reward textbook patterns over lived experience
It teaches devs to optimize for correctness over clarity.
For elegance over practicality.
But architecture isn’t code golf.
It’s not about showing how smart you are, it’s about creating a solution that works with the constraints you have, not in some ideal world. Start by mapping out your system’s context; just doing that might surface assumptions you didn’t even know you had.
🛠 Tool of the Week: Architecture Decision Records (ADRs)
Here’s what actually helps: capturing your thinking, not just your diagram.
That’s where ADRs come in.
An Architecture Decision Record (ADR) is a short write-up that answers 4 basic questions:
Context – what’s the situation?
Decision – what did we choose to do?
Alternatives – what else did we consider?
Consequences – what’s the cost, risk, or tradeoff?
It can be a Google Doc. A Notion page. A bullet list in a repo.
Whatever format works, the point is: this is the design you can revisit.
Not perfect. But honest. And that’s much more valuable.
✏️ Mini Challenge: Your First ADR
This week, try this:
Pick one decision you made in the last project or sprint
Don’t overthink it, even a small one works
Write a short summary answering:
1. What problem were you solving?
2. What options did you consider?
3. Why did you choose this one?
4. What are the tradeoffs?
5. What might you need to revisit later?Save it somewhere. Title it with the date.
That’s your first ADR.
Do this once a week and you'll build a habit most architects wish they had from day one.
“I used to think documenting decisions was a waste of time, now I wish I’d started sooner. I forgot why we picked our message queue, and when it caused issues months later... I had nothing to point to.”
👋 Wrapping Up
Thanks for reading.
That’s it for this week.
If you’ve ever felt stuck trying to get a design “just right,” I hope this gave you permission to make the best decision you can now and move forward.
Got questions about ADRs? Hit reply. I read everything.
Or, if you haven’t taken the 5-day From Dev to Architect free crash course yet, you can start it here. It's a fast, structured jumpstart into this kind of thinking.
Take care,
Bogdan Colța
Tech Architect Insights