Best practices are a great starting point. They represent the distilled experience of thousands of developers who ran into the same problems you're facing and found solutions that worked for them, in their context, with their constraints. That's genuinely valuable.
But here's where it goes wrong: developers stop at "it's a best practice" and never ask "is it the best practice for us?" They treat best practices like rules instead of what they actually are — recommendations from people who don't know your codebase, your team, your users, or your constraints.
The Appeal to Authority Fallacy
When debating architecture or implementation with engineers, I regularly hear: "We should do it this way because it's a best practice." That's not an argument. In formal logic, it's called an appeal to authority — the idea that something is correct because an authority said so, rather than because of the reasoning behind it.
Best practices are nothing more than experience from other developers who expressed what made sense for them in their context. Most of the time, their context will overlap with yours. But not always. And when it doesn't, following them blindly isn't engineering — it's cargo culting.
The fix is simple: every time someone says "best practice," ask "why?" If the answer is "because the docs say so" or "because everyone does it that way," that's a red flag. If the answer is a concrete technical reason that applies to your situation, great — now you have an actual argument, not an appeal to authority.
The Next.js Cart Disaster
I saw this play out at a major Swiss retailer. When I joined, the team was building e-commerce applications and had adopted Next.js with a strict "server-first" approach — because that's what the Next.js documentation recommended. Render everything on the server. Use Server Components everywhere. Minimize client-side JavaScript.
The problem? They applied this to the entire shopping cart and checkout flow. Every cart action — adding an item, changing quantity, applying a coupon — triggered a server round-trip. The whole checkout was server-rendered.
On paper, this followed "best practices." In practice, it was a terrible fit. We served only the Swiss market. Every cart is unique to each user — there's zero benefit in server-side caching of cart state. The server-first approach added latency to every interaction without giving us anything in return. No SEO benefit (Google doesn't index your cart). No caching benefit (every cart is different). Just slower UX for no reason.
It was hard to convince the team at first. "But the Next.js docs say server components are the default" was a real argument I heard multiple times. The appeal to authority was deeply ingrained. But once we moved the cart and checkout entirely to the client, the user experience improved dramatically. Interactions became instant. The code became simpler. And we didn't lose a single benefit that server rendering was supposedly giving us.
Drill It Down to Your Context
The lesson isn't "ignore best practices." The lesson is: treat them as a starting point, then drill them down to your specific context. Ask yourself:
What problem does this practice solve? Does my project actually have that problem? What are the trade-offs in my specific situation? Is the recommendation based on assumptions that don't hold for us?
Server-side rendering is excellent when you need SEO, when you serve content that's the same for many users, when you want fast initial page loads on slow connections. It's unnecessary overhead when you're rendering personalized, interactive content behind authentication that no search engine will ever see.
The Next.js team isn't wrong. Their recommendation is sound for the majority of use cases they designed for. But they don't know that your checkout is Swiss-only, that your cart is always unique, and that your users are on fast Swiss internet connections. Only you know your context. And only you can decide what practice actually fits.
Some Practices Are Almost Universal
Not all best practices need heavy contextualizing. Some are so fundamental that they apply almost everywhere. YAGNI over DRY — don't abstract until you need to — is one I've never seen fail in any context. Separating smart and dumb components — keeping business logic out of UI components — works whether you're building a banking app or an e-commerce site.
The difference? These practices are rooted in fundamental software design principles — separation of concerns, avoiding premature abstraction — not in framework-specific recommendations. The more tied a "best practice" is to a specific tool or framework, the more likely it needs adaptation to your context.
Build Your Own Playbook
The best teams I've led don't follow best practices — they have their own practices, informed by best practices but adapted to their reality. They've taken the time to understand why a recommendation exists, tested whether it applies, and written down what actually works for them.
This is what I mean by "invent your own." Not that you should ignore the collective wisdom of the industry. But that you should process it through your own engineering judgment instead of accepting it as gospel. Read the docs. Understand the reasoning. Then decide — with arguments, not authority — whether it fits.
The engineers who do this build better software. Not because they're smarter, but because they're thinking instead of following.