What a buying group must demand in its contract

A development contract is negotiated once, at the exact moment both parties most want to sign. Whatever is left out is not recoverable later: three years on, when the supplier no longer answers or their rates have doubled, your room for manoeuvre is precisely the room the contract left you. Here is the list we would keep in front of us during the review — including where it works against a supplier like us.

The general rule: buy the ability to leave

None of these clauses exists to prepare a divorce. They exist to make a divorce possible, which changes the entire balance of the relationship while everything is going well. A supplier who knows you can leave behaves differently from one who knows you cannot. The reversibility clause is not an act of distrust — it is what spares you from ever needing to feel any.

The second rule is more prosaic: a clause whose execution is not described does not exist. "The supplier shall provide documentation" commits nobody until the nature, the format, the recipient and the moment of delivery are written down. Every point below follows the same pattern — the wording to spot, and what to ask for instead.

What you are buying: rights, code, data

1. 1

   Assignment of economic rights, not a licence

   The trap: "the client benefits from a perpetual, irrevocable, non-exclusive user licence". Perpetual sounds reassuring and is not: a licence lets you use the software, not modify it, have it modified by a third party, or transfer it. Ask for an assignment of the economic rights on the bespoke developments, listing the rights transferred — reproduction, adaptation, distribution — for the full legal term and for all territories. Vague, blanket assignments are unenforceable in French law, so a short generous sentence protects you far less than a long precise one.

2. 2

   Ownership of the repository and of the accounts

   The trap: the code is "available on request" or held by an escrow agent. What to ask for: the repository is hosted on an account in the group's name, with an administrator on the group's side from day one, and the supplier works in it as a guest. The difference is not legal, it is practical — the day the relationship ends, you ask nobody for anything.

3. 3

   Ownership of the data, and a documented export format

   The trap: "the client's data remains the property of the client". Nobody disputes that; the question is how you get it out. Ask for a complete export in an open format, with the corresponding data dictionary, runnable by you at any time from inside the application. Not on request, not as PDF, not as a chargeable service quoted on the day you leave.

4. 4

   No blocking proprietary component

   The trap: an "in-house framework" or "proprietary technical foundation", presented as a productivity advantage. Ask for the list of components used, their licences, and a written commitment that no component required to run the application belongs to the supplier without a transferable licence. Source code that only builds against a private library is not delivered source code.

What you must be able to do without them

1. 1

   Operations documentation and environment rebuild

   The trap: "documentation will be provided at the end of the project" — it never is, or it arrives as a user manual. What to ask for: a written procedure allowing a competent third party to rebuild the whole environment from the repository, with dependencies, configuration variables, database schema and test data. Make it an acceptance criterion: a developer from outside the project follows the procedure and the application starts. That is the only test proving the source code delivery means something.

2. 2

   Reversibility and exit

   The trap: a "reversibility clause" with no content. What to ask for: a deadline, a list of deliverables (up-to-date code, data export, documentation, accounts and credentials, transfer of domain names and certificates), a price or an explicit free-of-charge statement agreed in advance, and an obligation to support the incoming supplier for a defined number of days. A reversibility quote negotiated on the day you leave is not a clause, it is a balance of power.

3. 3

   Continuity if the supplier fails

   The trap: nothing at all, or professional indemnity insurance mentioned with no limits. What to ask for: the insurance certificate with its cover limits annexed to the contract, and a clause triggering automatic handover of the deliverables if insolvency proceedings open. If you can get nothing better, insist at minimum that the reversibility clause applies as of right, without prior notice.

What governs the relationship day to day

1. 1

   A written definition of acceptance, and of what signature triggers

   The trap: "acceptance is deemed granted in the absence of feedback within eight days". What to ask for: an acceptance script listing the cases tested, a realistic period, a distinction between blocking defects and minor reservations, and an explicit statement of what signature triggers — payment of the batch, start of the warranty, closure of that batch's scope. Acceptance that closes nothing lets month six reopen what month two agreed.

2. 2

   Maintenance and correction commitments with actual deadlines

   The trap: "corrective maintenance included for one year", with no response time. What to ask for: severity levels defined in writing (blocking, major, minor), an acknowledgement time and a restoration time per level, the hours covered, and what happens when a deadline is missed. Without written severity levels, everything is minor to whoever has to fix it.

3. 3

   A change-order clause

   The trap: no clause at all, or "any request outside the scope will be invoiced separately". What to ask for: the procedure itself — written qualification, price given before the decision, arbitration, signature, update of the scope document — plus an explicit ban on starting out-of-scope development before signature. This clause protects you from a surprise invoice as much as it protects the supplier from unpaid work.

4. 4

   A named team in the contract

   The trap: "a team of senior developers will be assigned to the project". What to ask for: the people, their roles, their allocation, and a replacement clause with notice, equivalent profile and an overlap period. And the cheapest question you will ever ask: is any of the development subcontracted, and to whom?

The three clauses never to accept

1. A perpetual licence presented as equivalent to an assignment of rights. They are not comparable: one lets you use, the other lets you decide. A supplier explaining that "in practice it is the same thing" is telling you the exact opposite of what they believe.
2. Tacit acceptance. A clause deeming a delivery accepted in the absence of feedback within a short window converts your workload into approval. During the annual close or a declaration campaign, your permanent team will read nothing for three weeks — and the contract will consider that you accepted everything.
3. Hosting and domain names in the supplier's name. It is the quietest and most expensive clause of all: it mentions neither rights nor code, and on its own it makes an exit impossible without an outage. The hosting accounts, the domain name, the certificates and the database credentials are in the group's name, invoiced to the group, from day one.

None of these demands raises the price of a well-run project. They raise the price — or drive away — the supplier who was counting on your dependency to make a deal signed too low profitable. That is exactly what they are for: they do not sort contracts, they sort suppliers, and they do it before signature rather than three years afterwards.