Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Angle
A large account's technical requirement — the database inside its own cloud subscription, its email gateway, its language model provider — is negotiated on its motive, never on its feasibility. The motive says how much it is enough to concede; answering the request as it was formulated amounts to conceding the maximum without knowing why, and that maximum is paid for afterwards in divergence of the product, on lines no cost table shows.
Synthesis
A large group is evaluating your payroll software. The deal is moving forward. Then a sentence lands: "the database has to be in our Azure subscription".
The discussion that follows almost always takes place in the same spot: is it feasible? Yes, technically. How long? Two months. You cost it, you commit, you move on.
That discussion has skipped the only question that gives you the upper hand: why this request. An ISO audit to pass, a security policy that forbids data outside its own tenant, a cybersecurity team that wants its logs in its own monitoring tool. These are not judgments on your competence — nobody thinks the customer will host better than you. It is control: being able to answer for one's data in front of one's auditor.
The motive matters because it sets the dosage. If the need is to prove that the data does not leave the European Union, a hosting region and a written commitment answer it. If it is to hold the encryption key, a customer-managed key answers it. Neither of these two needs requires the database inside its subscription. Answering the request as it was formulated means conceding the maximum for a motive you have not identified.
Because what you concede has a price, and it is paid on lines nobody tracks. The database lives at the customer's: every release that touches the data structure becomes a procedure to send, a validation to wait for, a maintenance window to book. The first customer takes it on Tuesday, the third postpones to the following month, and three months later your fixes are tested against four different database states. What is lost there is exactly what made the model worthwhile: a single product you move forward for everyone at once. The infrastructure line, meanwhile, has gone down — and that is the one the salesperson sees when offering a discount.
There is one case where the calculation reverses: a building block that differentiates nothing can on its own prevent the sale. SSO distinguishes no payroll software from its competitors, and its absence is enough to eliminate you. So you build it, not for what it brings, but for what its absence costs. The question is never "does this create value" — it is "what does this open, and on which line is it paid for".
Hence the conclusion, which is not a technical one. These requirements are not special cases to be handled one by one: they are the governance culture of a market segment. Deciding to sell there means accepting that constraint as a given of the market, costing it once and for all, and negotiating each request on its motive rather than on its feasibility.
Tensions / contradictions
Two notes do not say the same thing about what can be given up. One holds that replacing a provider without changing the value makes the service substitutable — hence that you must resist; the other that substitution stays costly as soon as the block carries the durable state — hence that the risk is lower than it looks. The border between the two is not drawn.
Also unresolved: the thesis calls for negotiating on the motive, but nothing guarantees that the person across the table knows it. A requirement relayed by a buyer may have lost its reason along the way.
Questions
- How do you surface the motive when the person across the table is only passing on an internal rule?
- Up to how many different database states can a team hold before qualification becomes impracticable?