Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.
It's a sliding scale. You have to pander to them to some degree - there's no choice. But it takes grit to refuse to e.g. branch your core code or otherwise compromise your architectural integrity.
The problems are when the sales team does not appreciate the downstream costs of just letting this one patch in. And when you're a struggling startup, sometimes they're right and the social proof of the deal (and the revenue) make it a good choice to compromise your principles this once.
Q: Can your system do X?
A: Yes (doesn't matter what the question is, or that an entire add-on would have to be built that could never be cost justified).
Q: As a company we do things like this, will your system work?
A: Yes, our product works with your process, no matter what it is.
I have observed this to be true. Customers particularly love the second one, so telling someone that they must change their process to work with your super simple un-customizable product can often be a deal-breaker.