When NOT to use a tool/paradigm/workflow

Using the right tool/paradigm/solution/library/workflow for a job is widely regarded as a good idea.

It's the opposite of cargo-culting, which means blindly using a tool because others do, without necessarily knowing their reasons.

< / obvious >
< point >

Everyone who is selling tools will usually praise theirs as silver bullet for a wide range of use-cases.

What is missing is the information, when not to use it, or cases where that tool is not a good choice.

Lately I have come to appreciate tool-authors, vendors, experts and teachers who clearly state that

our book may not be for you.
you should use a simpler approach.
this library introduces too much overhead for your project-size.

It's an act which might prevent some purchases or downloads, but

it immediately builds trust.
it provides usable information.
it can prevent frustration in the long run.

Positive examples I came across more or less recently:

• "You Might Not Need Redux" by the author of Redux

• "When and Why to Use Docker"

I'm curious about more examples of "do not use our product if"!