The Enterprise Customer That Breaks the SaaS Model

A growth company signs a customer several times its size- the kind of account salespeople call a whale- and the board starts looking for the maturity gap. Security review boards, change management, disaster recovery testing, a list of contractual requirements the company has never seen before.

Those gaps are predictable, and unless something is badly broken, I would rather see a credible plan and a person responsible for it than watch a forty-person company spend twelve months trying to look like a Fortune 500. The gap I care about is in the codebase.

Engineering forks the product. They copy the software, change it for the large customer, and keep the original running for everyone else. Four or five engineers are pulled from the regular product groups and assigned to the whale account; in other words, they “ring-fence” a team.

Fork is a friendly word. What the company has actually done is start shipping a second product while charging like it has one.

One reason software businesses command extraordinary valuations is operational leverage. Build the product once, sell it repeatedly, and revenue grows much faster than the engineering organization required to produce it. The moment engineering capacity starts increasing customer by customer, the leverage investors thought they were buying starts disappearing.

Think of two cars from the same model year. Most of the parts are still interchangeable. That is never the problem. You find out which parts don’t on a Sunday afternoon when one of them breaks.

Every feature built after the fork has three possible outcomes. Build it on both versions. Test it on both versions. Or let one version go without it. The third answer wins surprisingly often because it costs nothing this quarter, and the versions drift.

Some CTOs will tell you they avoided all this because everything still lives in one codebase behind feature flags. That can be perfectly sensible when a flag is temporary and controls the release of a feature. Permanent customer-specific flags are a different animal. Ten independent on/off flags permit 1,024 possible combinations. Seventeen permit 131,072. Nobody tests 131,072 combinations. The team tests the configurations it expects customers to use, and then a customer finds one it didn’t expect on a Sunday afternoon.

The org chart drifts at the same time. A dedicated (ring-fenced) customer team almost never works. The trouble starts when engineers are repeatedly borrowed from the core teams, work the urgent account request, return to their old roadmap, and get pulled back three weeks later. Two sets of priorities now own the same people, while mid-level management becomes increasingly territorial over them.

I have seen attrition reach 40% in organizations that operated that way long enough. They were working constantly. Nobody could give them a stable definition of what mattered.

On his way out, one of them said he felt like a firefighter on a treadmill. Ten out of ten anxiety every day, and it never, ever ends. He took a pay cut to work where he could actually “build something.”

There is a good objection to all of this, and sometimes the fork is the correct decision. The revenue is real. Losing the account may be worse. A large customer may have a legitimate requirement the standard product cannot support quickly enough, and refusing every exception in the name of architectural purity is just as expensive as accepting every one.

I have approved forks that put us in the weeds for a quarter and fought forks that merged back without incident. I have been wrong in both directions.

If you fork, treat it as financing a temporary second product. Give the divergence an owner, decide what has to happen before the versions can converge, fund that work, and put it on a calendar while the customer is still exciting. Because “we’ll merge it back later” is where the economics usually stop working. Consolidation produces almost no new revenue. The next feature does. The next customer does. The urgent request sitting in the sales pipeline does.

So cleanup loses.

Then the second whale arrives, which is supposed to be good news and is usually part of the investment thesis. The company proved it can sell to one enterprise customer and now intends to repeat the motion. Except the second customer wants its own set of exceptions.

Two customers. Three products. Same engineering organization. Or worse, three products and a larger engineering organization. A SaaS company is supposed to add customers without adding proportional product-development cost. Once every large account requires its own engineers, release path, testing burden, support knowledge, and architectural exceptions, the revenue is still recurring and the operating model underneath it is no longer SaaS.

The company has started selling engineering labor disguised as software.

The damage shows up in the financials before anyone names the cause. Engineering headcount grows with enterprise revenue. Gross margin improvement stalls. Release velocity slows. Professional services work leaks into R&D. The cost of supporting each additional large account rises instead of falling. The multiple was based on the opposite assumption.

The fix is to give customer variation a legitimate place to live. One core product, one release train, and customer-specific behavior pushed into configuration, adapters, or implementation modules that can change without creating a different version of the core. Sales will fight it, because it means an urgent customer request goes through implementation instead of straight into the product, and at a forty-person company running two formal organizations may be heavier than the problem you are trying to solve.

There is a cheap diligence test for this.

Ask the CTO for the number of production versions, the number of long-lived customer-specific flags or branches, and the engineers substantially dedicated to individual customer accounts. Then ask finance to put engineering headcount next to enterprise revenue for the last three years. If revenue doubled, what happened to the people required to build and support the product?

Then ask the CTO one more question. “When the core product ships a feature, does every enterprise customer receive the same release?” If the answer begins with “it depends on the customer,” keep going.

The fork looks almost free in year one. That is why companies do it. The cost appears later, when the enterprise sales motion starts working and every new customer increases the number of product states the organization has to support. It appears again at exit, when a buyer’s technical diligence team asks how many versions of the product are running in production. The better buyer asks a harder question. How many more engineers does this company need for every dollar of enterprise revenue it adds?

Somebody has to answer with a number.