When should you NOT use design patterns?

Design patterns should not be applied mechanically to every problem. Overusing them leads to over-engineering — adding unnecessary layers of abstraction, indirection, and complexity for problems that a simple function or class would solve more clearly. Avoid patterns when: the codebase is small and unlikely to grow in the anticipated direction, the pattern adds multiple classes where one would do, you are applying a pattern preemptively "just in case," or the team is unfamiliar with the pattern and will struggle to maintain it. The costs of patterns (added classes, indirection, learning curve) must be outweighed by the benefit (flexibility, reuse). As a rule: reach for simple solutions first; introduce a pattern only when a concrete need emerges.