The temptation is strong for a software publisher to accept custom development to win a client. It's often a major strategic mistake that dilutes the product, bloats maintenance, and destroys the business model's scalability.
There are two fundamentally different business models in software: the software publisher (selling the same product to many clients) and the services firm (developing custom solutions for each client). These two models have radically different economics, organisations, and cultures. The problem arises when a publisher starts drifting toward custom work to satisfy a client — often with the best of intentions.
The publisher's logic
The publisher builds once, sells multiple times. Its value comes from scale effects: each additional client generates marginal revenue without proportional marginal cost. The product improves for everyone at the same pace. The roadmap is driven by the common needs of the installed base, not by one client's requests. This model demands rigorous discipline: saying no to requests that only apply to one particular case.
The custom development temptation
A major client arrives, interested in the product, but with particular needs. They're willing to pay for bespoke development. The proposition seems win-win: the client gets what they want, the publisher funds its development. In reality:
- Custom code must be maintained in parallel with the standard product — forever
- Product updates must be re-qualified against the custom version
- The team spends time on one client instead of improving the product for everyone
- The roadmap becomes hostage to that client's particular requests
- If the client churns, all that work has served no one else
Produit et services peuvent coexister — à condition de maintenir une séparation stricte.
When custom work is justified
There are legitimate cases: a connector to a third-party system that other clients also use (it becomes generic), a feature driven by a pioneering client who anticipates a market need, or a services project clearly separated from the product, with a dedicated team and transparent billing. The golden rule: if you can't sell it to three different clients, it's not a product feature — it's a service delivery.
The organisation that protects the product
Mature publishers clearly separate teams: a product team that builds the core, a services team that handles custom work and integrations. Services revenue sometimes funds the product — but the two activities remain watertight. Without this separation, the product ends up resembling a collection of edge cases, impossible to maintain and impossible to sell simply.