Every experienced developer has a mental library of solutions that have worked before. That’s a good thing — it means you’re not starting from zero every time.
But there’s a pattern worth watching out for: reaching for a familiar architecture not because it fits the current project, but because it’s comfortable. Because it worked last time.
The Problem With Familiarity
When a new project starts, teams often gravitate unconsciously toward whatever structure succeeded on their previous one. The intention is sound — reuse what works. But the execution fails when nobody stops to ask whether this new project actually resembles the old one in any meaningful way.
Consider the difference between a corporate website with static pages and an internal business platform with complex workflows, multiple user roles, and significant scalability requirements. On the surface, both might involve “pages” and “users.” Below the surface, they have almost nothing in common.
Applying the simpler architecture to the more complex problem doesn’t save time — it creates a maintenance burden that grows quietly until it becomes impossible to ignore.
Three Questions Worth Sitting With
Before committing to an architecture, I’ve found it useful to ask three questions. They take under a minute to ask. They can take days to answer properly — and that’s the point.
Fit — Does this solution actually address the current project’s needs, or does it address what I imagine those needs to be based on past experience?
Gap — What is genuinely different about this problem compared to the cases where I’ve used this solution before?
Tune — Given those differences, what would need to change right now to make this architecture appropriate for this context?
These aren’t rhetorical questions. They require honest answers, and honest answers require actually looking at the new project on its own terms rather than through the lens of previous ones.
Using AI as a Thinking Partner
One approach I’ve found valuable here is using AI not to generate code, but to pressure-test assumptions. Asking an AI to challenge your architectural choice — to surface alternative approaches, point out hidden assumptions, or identify where the analogy to a previous project breaks down — is a different and more useful activity than asking it to produce an implementation.
The goal is to deepen the three questions above, not to skip them.
The Underlying Principle
Reusing patterns and solutions is efficient. Reusing them without checking whether they fit is just comfortable — and comfort is a poor substitute for judgment.
Every project deserves to be understood on its own terms before a structural decision gets made. That moment of genuine evaluation, even if it confirms that the familiar approach is the right one, is what separates a deliberate architectural choice from a habit.
How do you make sure the solution you’ve chosen actually fits this problem — not just the last one that looked similar?