MRR vs custom development revenue. The white-label trap.

Every white-label platform business eventually faces a fork it usually does not notice it is at. One path is recurring revenue: clients pay a monthly fee to use the platform, the revenue is predictable, and the company’s value is a multiple of that recurring base. The other path is custom development revenue: clients pay for the platform to build the specific things they need, the revenue is large and immediate, and the company gets very good at building whatever the next client asks for.

Both paths produce revenue, but only one produces a software business. The trap is that the custom development path feels like the faster route to revenue “now”, the clients are happy to pay for it, and the cash arrives sooner than recurring revenue compounds. So the company drifts toward custom work, the engineering team optimises for delivery rather than product, and three years later the company has good revenue and a bad business.

From my experience, the custom development revenue is genuinely useful, it funds the team and proves client demand, but it has to be contained inside a structure that protects the recurring base, or it eats the business it was supposed to fund.

Why the trap is so easy to fall into

The custom development path is seductive for reasons that all look like good business sense in the moment.

First, the cash is immediate. A client who needs a specific module built will pay for it now, in a lump, while recurring revenue takes months of the same client paying a monthly fee to reach the same number. For a company that needs cash, the custom project is the obvious yes.

The client is asking for it. Custom development revenue comes from real client demand, which makes it feel validated. The client wants the feature, is willing to pay, and will be happier once it ships. Saying no to that feels like leaving money and goodwill on the table.

The team is good at it. A platform company has engineers, and engineers can build. Taking the custom project uses capability the company already has. The alternative, building general product that any client can use, is harder, slower, and produces no immediate revenue while it is underway.

Each individual decision to take the custom project is defensible. The trap is the aggregate. A company that says yes to every defensible custom project becomes a company whose revenue is mostly project-based, whose engineering roadmap is set by whichever client paid most recently, and whose product is a pile of client-specific features rather than a coherent platform.

What the trap costs

The cost is not visible in the revenue line, which is exactly why the trap holds. The company is growing revenue, the clients are paying, the team is busy. The damage is structural and shows up in four places that do not appear on a monthly revenue chart.

The multiple.

Recurring software revenue is valued at a high multiple because it is predictable and it compounds. Custom development revenue is valued at a low multiple because it is project-based, non-recurring, and dependent on continuous sales effort to replace. A company that is 70% custom revenue is valued like a consultancy even if its total revenue exceeds a pure-software peer, because the buyer is pricing the recurring base, not the project pipeline. The custom revenue that felt like success is the thing capping the exit valuation.

The roadmap.

When custom projects drive engineering, the product roadmap is set by the last client to pay rather than by a coherent product strategy. The platform accumulates features that serve one client each, the technical debt grows, and the general product that would serve the next hundred clients never gets built because the team is always delivering the specific thing the current client paid for.

The margin.

Custom development looks high-margin on the invoice and is low-margin in reality, because the true cost includes the maintenance of every client-specific feature forever, the support burden of a fragmented codebase, and the engineering time diverted from a product that would have served everyone. The margin that looks healthy per project is unhealthy across the portfolio once the long tail of maintenance is counted.

The concentration.

Custom revenue concentrates in the clients large enough to fund custom work, which are the clients whose loss hurts most. The company becomes dependent on a handful of accounts that each fund a custom roadmap, and the bargaining power shifts to those accounts because they know the company is built around their projects. The recurring model spreads revenue across many clients and keeps the bargaining power with the platform.

The structure that contains it

The answer though is not to refuse custom development. Custom revenue funds the team, proves demand, and builds the client relationships that recurring revenue grows from. The answer instead is to contain it inside a structure that converts custom work into product wherever possible and protects the recurring base everywhere.

Price custom work to reflect its true cost.

Custom development should be priced at a rate that includes the lifetime maintenance burden, not just the build. If the build is 200 hours, the price reflects the 200 hours plus the years of maintenance the feature will require. Priced correctly, custom work is either genuinely profitable or the client declines, and both outcomes are better than underpriced custom work that loses money slowly.

Convert custom into product by default.

Every custom project should be evaluated for whether it can become a general product. A feature built for one client that ten clients would use should be built as platform capability, priced into the recurring model, and offered to all. The custom project becomes the funded prototype for a product feature. The client who paid for it gets it first; the platform gets a new recurring-revenue capability.

Cap the custom share deliberately.

The company should set a target ratio of recurring to custom revenue and manage it. A platform business that wants a software multiple keeps custom revenue below a deliberate threshold, refuses custom work that would push it over, and treats the ratio as a managed metric rather than an accident of which projects came in. The threshold is a strategic choice, but the discipline of having one is what separates a platform from a consultancy that drifted.

Protect the recurring base from custom pricing.

The pricing discipline on recurring revenue must not be eroded by custom work. A client who funds a large custom project will ask for a discount on the recurring fee, and the company that grants it has traded durable recurring margin for one-time project revenue. The recurring price is protected; the custom project is priced on its own terms.

How to tell which business you are running

The honest diagnostic is the revenue mix and its trend. A platform business running correctly has a large and growing recurring base, with custom development as a contained and deliberate minority that mostly converts into product. A platform business that has fallen into the trap has a recurring base that is flat or growing slowly while custom revenue grows fast, and an engineering team whose time is mostly spent on client-specific delivery.

The test that cuts through it: if the company stopped taking new custom projects tomorrow, would the recurring revenue sustain the business? If yes, the platform is real and custom work is a supplement. If not, the company is a consultancy that has been describing itself as a platform, and the recurring revenue is the supplement to a project business.

The second test is the engineering split. What share of engineering time goes to general product versus client-specific delivery? A platform with a healthy structure spends most of its engineering on a product that serves everyone. A platform in the trap spends most of it on features that serve one client each. The split is visible in any sprint board and it tells the truth that the revenue line obscures.

Why this matters more for white-label than for SaaS

The trap is sharper for white-label platforms than for standard SaaS because white-label clients have more reason to ask for custom work and more leverage to get it. A white-label client is building their own branded product on the platform, so their requirements are specific to their market, their brand, and their regulatory position. The custom requests are constant and they are legitimate, which makes them harder to refuse than the feature requests a standard SaaS receives.

White-label clients are also fewer and larger than SaaS users, which concentrates the revenue and amplifies the bargaining power of any single client. A SaaS business with ten thousand users can ignore the custom requests of any one. A white-label platform with thirty clients cannot ignore the request of a client that represents a meaningful share of revenue, so the pressure to take custom work is structurally higher.

This is why discipline matters more in white-label. The forces pushing the company toward the custom-development trap are stronger, the clients are more capable of pushing, and the drift is harder to reverse once the revenue base is concentrated in a few clients funding custom roadmaps. The white-label platform that wants a software multiple has to defend the recurring base more deliberately than a SaaS business would, precisely because the pull toward consultancy is stronger.

The position to hold

A white-label platform is a software business that funds itself on recurring revenue and uses custom development as a contained, well-priced, product-converting supplement. The moment custom revenue becomes the main event, the company has changed what it is without deciding to, and the change is priced into every future valuation conversation.

The discipline is to take custom work on the platform’s terms rather than the client’s, to convert it into product wherever the demand generalises, and to protect the recurring base as the thing the business is actually built on. The custom revenue is useful. It is just not the business, and the companies that confuse the two end up with good revenue and a low multiple, which is the white-label trap doing exactly what it does.