When Best Practices may not always fit

“We follow best practices.” It sounds reassuring. It’s meant to. But it’s the vaguest promise in a vendor pitch, and it deserves a follow-up question every single time.

Best practices for whom? What’s best practice for a bank processing millions of transactions looks very different from what’s best practice for a startup trying to find product-market fit. One demands rigorous compliance, audit trails, and redundancy. The other demands speed, flexibility, and the ability to change direction next month. Applying one set of standards to the other doesn’t make you safer. It makes you slower.

When a vendor says “best practices,” they usually mean “our standard process.” That’s not a criticism. Having a repeatable process is a sign of maturity. The problem is when that process gets applied regardless of context. Your ten-person company shouldn’t be built with the same ceremony as a Fortune 500 platform. That’s not rigor; it is overhead.

The more subtle version of this is when best practices get used to justify complexity. Extra layers of infrastructure, elaborate deployment pipelines, monitoring frameworks which are all defensible in the abstract, all potentially overkill for where you are right now. Every layer has a maintenance cost, and someone is going to pay it long after the vendor moves on.

The questions to ask: “What is best practice for a company at our stage and scale? What would you do differently for us versus a larger client?” A vendor who gives you a thoughtful answer has the judgment to match the solution to the problem. One who gives you the same answer regardless of who’s asking is selling a process, not a partnership.

The best practice for an early-stage founder is working with people who know when the textbook doesn’t apply.

When has “best practice” advice actually slowed you down?