The old objection to customisation — that the engineering cost to build and maintain is too high — no longer applies. You can give every client exactly what they want. Build bespoke for the bank that needs a custom report format. Build a different data loader for the client whose compliance team interprets the regulation differently. If something breaks, rebuild it. The economics that made customisation dangerous have changed.
It starts with a reasonable decision.
The conversation about product-led growth happens in almost every scaling B2B company at some point. The CEO believes it. Says it in the all-hands. Means it when they say it.
Then the £500k deal lands. A large client — a bank, a payments platform, an enterprise with real commercial weight — asks for one specific thing. A custom report format. A slightly different data field for their compliance team. The CRO says it's just a small thing.
The product principle is abstract but the revenue number is real. The justification is "just this once."
Then another client asks for something similar but different. Then a third. Each decision is locally rational. The commercial logic is sound every single time. Nobody is making a bad call in the moment.
Three years later you have 47 configurations, different data models for each client, different ETL pipelines pulling data in different shapes, and a product that cannot be demoed the same way twice — because no two clients have the same product.
The code was never the expensive part.
Walk into a scaling B2B business that has been saying yes to custom requests for three years and look at the org chart — not just the product team, the whole company. Product and engineering are a fraction of it. The rest? Implementation teams onboarding each bespoke configuration. Support teams where every person needs to know their specific client's setup. Product managers who are actually project managers, executing someone else's spec rather than defining a product direction. A sales team running a proof of value process that cobbles together APIs and workarounds and presents it to the client as a product — because the actual product can't demo what was promised.
None of that cost appears on the engineering budget. All of it appears on the org chart. That is the cost of customisation — not the engineering hours, but the organisation you have to build to service the complexity you created.
The product full of MVPs nobody went back to.
Custom features get built to 80% because the next deal arrives before this one is finished. The feature ships as an MVP, lives as an MVP, and nobody goes back. Multiply that across three years and you have a product with no depth anywhere — dozens of things started, delivered just enough to satisfy the original promise, and never improved.
And nobody turns anything off. One client churns. The other goes quiet. Nobody decommissions the feature because nobody is sure who owns it or whether it's still in use. So it stays — tested in every release, carried through every migration.
AI cannot fix the judgment calls this creates. Which configurations are worth maintaining? Which clients need to be migrated? When does a promise sales made two years ago get retired? These are commercial decisions requiring context no model has access to. The judgment load doesn't shrink when building gets cheaper. It grows, because you've said yes more often.
Then you go blind.
When your product fragments across dozens of configurations, you lose the ability to see it. Feature usage data becomes meaningless when every client uses a different feature set. You don't know what's being used and what isn't, because "used by whom and in what configuration" are questions you can't answer cleanly. You discover features by accident — in a research session, in a conversation with a client, in a benchmark report from a consultant who tells you that you have a capability you thought was still on the roadmap.
The product managers cannot manage the product. They are spread across 40 features with few users on each and there is no time to go deep on anything. No data to know how to improve. No way to ask the right questions across the client base when every client's experience is unique.
And when people leave — the engineer who built the integration, the PM who knew what the CRO had promised in a meeting that couldn't be recorded because the client's security policy didn't allow it — that context leaves with them. AI can read the code and generate documentation. It cannot reconstruct why the decision was made, what the commercial commitment behind it was, or whether that client is still strategically important three years later.
What the companies getting this right do differently.
The companies that avoid this don't have better engineers or more disciplined sales teams. They make different decisions earlier.
First — invest in the core
A deep, well-architected foundation with a consistent data model, clear platform boundaries, a product that does fewer things completely rather than many things partially.
Second — decide in advance what yes means
What can be configured, what can't, and what it costs the product when something falls outside that boundary. A client can have their report format. They cannot have a different data model. That distinction has to be architectural, not just a policy you try to hold in a sales negotiation.
The real cost — a note for CEOs and investors.
The revenue multiple you are optimising for is real. So is the cost of unwinding what you built to get there.
The due diligence question shouldn't just be about how much revenue you have. It should include: how many of your features are unfinished promises? How many custom implementations belong to clients who have churned? How much of your headcount exists to service complexity rather than build product? What it will cost the next owner to standardise what you built across dozens of bespoke configurations?
That is what a sophisticated buyer will find. And they will price it accordingly.
