And if you disappear?
The question every organisation asks before entrusting a production tool to a small vendor. It is legitimate, and it has a simple answer: do not depend on us in order to carry on.
The doubt is not about competence
If you let us come and present a solution, the need is real and the work looks sound to you. The remaining question is not « can you do it », it is « what happens if you are no longer there ».
Many vendors answer with arrangements that trigger the day things go wrong. We prefer the opposite: that nothing needs to trigger, because you already hold everything required to carry on without us.
1. The hosting can be in your name
We always offer to open the server with a French host, in your name, on your payment method. You own it, we are merely guests, and you can revoke our access in one move — without asking us.
In practice most companies prefer us to handle it: one less thing to carry. But the option exists, it is written into the proposal, and that is what matters. The host's attestations — data location, certifications, GDPR compliance — come with the proposal rather than being chased afterwards.
2. The source code is handed over as we go
Not on delivery, not on request: continuously. The code repository can be yours from day one, with the provider of your choice, and we work in it the way a contractor works on your premises.
At any moment you therefore hold everything that has been written, with its history. There is nothing to trigger, nothing to claim, and no third party to involve in order to obtain it.
3. What we deliver is built to be taken over
Code nobody else can pick up has not been delivered, it has been lent. So we deliver with it: the install procedure from a bare machine, the environment variables and what each one does, how backups are taken and — what almost nobody documents — how they are restored.
The test we hold ourselves to is simple: a developer who has never seen the project must be able to bring it back up from the repository alone. If that is not true, the documentation is not finished.
What this changes in practice
You depend on us for what is left to do, never for what is already done. The server is yours, the code is with you, the recovery procedure is written down.
It is less spectacular than a legal arrangement, and it is sturdier: a fallback mechanism has to be triggered, evidenced, sometimes argued. A repository you already hold does not trigger — it is simply there.
What you should know
- Holding the code does not mean being able to take it over overnight: someone has to read it. We document to shorten that delay, not to pretend it is zero.
- Hosting in your name gives you control, and with it responsibility for access: nobody can restore it for you if you lose it.
- We are a small outfit and we do not hide it. If your organisation requires formal continuity commitments, they belong in the contract — let us discuss them before the proposal, not after.
- For a small project, part of this apparatus is disproportionate. We will tell you rather than bill you for it.
Does your legal department have specific requirements?
Send them over. Continuity commitments are drafted in the contract, not on a web page — and it is better discussed before the proposal than after.
Reply within 48 business hours · No commitment · Confidential