IMO, try to avoid fork - you'll never be able to merge it back anymore, a fork splits the product into 2; think what will happen when you get +1 more "special"

IMO, try to avoid fork - you'll never be able to merge it back anymore, a fork splits the product into 2; think what will happen when you get +1 more "special" customer. In the 2nd company where I encountered this challenge, I introduced a single global cross-cutting interface, giving de facto hook points in the code. Implementations were specialized per customer; the default behaviors went by "vanilla" (90% were empty implementations). This still led to a mess and complex indirections, but at least we were getting some isolation and encapsulation (a.k.a. decoupling). In particular, in case we lost one customer, we could quickly scrap all the specialized cruft with a single clean cut. And let me tell you, they wanted crazy customizations sometimes, and we were not in power to resist. edit: Also, when analyzing, you could at least keep in mind only the common core + single customer's tweaks; other customers were completely off your mind. And you could try and see how this customer's tweaks interact between them in one place. edit 2: Note that some behaviors were still kept in the main codebase if they looked reasonably useful for future, and just the choice would be in the customizer then. Sorry if what I wrote is too chaotic :/ edit 3: Still, remember the "[refactoring] rule of three" - as applied here, first just hack your new behavior into a personal fork as if it was the only codebase, and only when it works look where to introduce decoupling points. You will 99% always see them much better from position of hindsight than when trying to predict them initially. That said, I'm not yet aware if there's a way to reasonably mitigate a huge increase in complexity when supporting multiple customers.