The rule of three
Developers are usually taught to follow the DRY principle, Don’t Repeat Yourself.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system - The Pragmatic Programmer
While this only mentions knowledge, people use it to describe any kind of code that’s repeated. To “clean” this up common code gets abstracted out using whatever tools the language supports. In general this is a good thing.
The problem is that if you do this the first time you notice some duplicated code you don’t have enough information to know if the abstraction is going to generalise. If you get it wrong then you have to fight the abstraction when you try to build on top of it.
duplication is far cheaper than the wrong abstraction - Sandi Metz
It’s best to wait until you have three or more examples, that way you’ve a much better chance of picking the right abstraction.
This doesn’t just apply to code. If you think two customers are going to want the same feature can you find a third to confirm? Or will a third customer want something a bit different?