Software project rescue: your code, your accounts, your project moving again.

For companies in Europe, and US or UK companies with software serving European users, whose vendor went quiet, missed its milestones, or will not hand over the source code. What you own is secured first, the takeover is assessed in writing, then the work is finished on a fixed fee.

Tell us about your projectA 20-minute video call Who owns contractor code?

Keys in your name first
Written takeover assessment
Fixed fee to finish

A person studying a planning board covered in sticky notes, most of them still in the to-do column (illustration photo)

What is a software project rescue?

Taking over a software project that has stalled with its original vendor: secure the assets, establish what actually exists, decide whether to continue or rewrite, then deliver software that builds, deploys and runs under your control.

The situations look alike from one company to the next. Milestones slip and the answers get shorter. A payment is due and the demo keeps moving. Or the relationship ends and the vendor treats the code, the hosting account and the credentials as leverage. The first question is never technical: what do you hold today, in your own name?

Ownership of the code itself is a contract question, and it is often not what clients assume: paying for the work does not always transfer it. Our article on who owns the code your contractor writes covers the clauses to look for. For a dispute already under way, talk to counsel.

Six things you must hold, and how to check you do.

Go through these before the next payment to any software vendor, rescue or not. Each line takes minutes to verify, and each missing one is a dependency nobody put in the quote.

Six software assets a client must hold, why each matters, and how to check it is held
Six software assets a client must hold, why each matters, and how to check it is held	Why it matters	How to check you have it
Source code repositories	Without them, every change depends on the vendor, and a new team starts from nothing	You are an owner of the repository organization, not a guest, and the full history is there
Cloud and hosting accounts	Whoever holds the account can stop the product, and receives the security notices	The account is in your company name and billed to you; the vendor has a user, not the root
Domain names and DNS	A domain registered by the vendor can take your site and your email offline in one expiry	The registrant is your company, and renewal notices reach an address you read
Credentials and API keys	Payment, email, maps and AI services are wired in with keys someone owns	A password vault you control lists every key, and each third-party contract is in your name
Build and deployment procedure	Code nobody can build is an archive, not a product	Someone outside the vendor has built and deployed it from the written procedure
Documentation and decision log	It carries the reasons behind the design, which the code does not	A new developer can find why each significant choice was made without calling anyone

Assets first, code second: what you hold after each stage.

The order protects you: a product can be stopped from a hosting console long before anyone decides what to do with the repository.

This week
The keys moved to your side.
Repositories, cloud and hosting accounts, domain, app store accounts, third-party API keys, password vault. Whatever is still in the vendor's name is noted, with what it takes to transfer it.
A few days
A written takeover assessment, yours to keep.
We build the code on a clean machine, deploy it to a test environment and compare what runs with what was promised. What works, what is missing, what it costs to continue. Yours even if you go elsewhere.
On evidence
Continue or rewrite, both options priced side by side.
Most projects are worth continuing: business logic already written is expensive to rediscover. The decision comes from the assessment, not from a new vendor’s instinct to start again.
Fixed fee
The scope finished, and the trap closed in writing.
Written acceptance criteria. The contract says, before we start, that the source code, the documentation and the credentials are yours on payment, and one of your people is trained to run it.

100%of the product lead handed back in-house, no hidden recurring contract

leads.fr case study, 2024

leads.fr, B2B lead generation

A stalled team restarted, then handed in-house.

The problem: Sprints had turned into planning meetings that decided nothing, developers worked on topics nobody had prioritized, and leadership no longer knew what to ask of its team.
What was delivered: The product lead taken over, delivery restarted, an internal product owner recruited and supported until operating alone. Then we left, with no residual retainer.

Read the case studies

Deposited code is not a project you can run.

A software escrow agreement protects you against a supplier that disappears: the code sits with an independent agent and is released on a defined event. It does not replace what a rescue needs, because the deposit holds files, not the knowledge of how they fit together. On a project built for you, the stronger protection is simpler.

How we contract every engagement

The repository in your organization from day oneThe vendor is a member, not the owner.
One of your people trained along the wayFor Expertise France, the source code and the hosting had to stay under the client’s control: a local project manager and two local developers were trained and the sources handed over so the country could host the systems itself.

Who reads your code, and who you can call once it is back.

The engineers who assess the takeover are the ones who finish the work. Nothing is subcontracted in between, so the person who found the gaps is the one who closes them.

Clairmont, technical leadBuilds the code on a clean machine, reads the architecture, writes the takeover assessment.
Laurent, founder and CTOSecures the accounts with you, prices the two options and runs the decision.

What you sign for a project rescue, in short.

Assessment: A fixed duration and a fixed price, agreed at the start. The written inventory is yours even if you stop there.
Price: The continuation or the rewrite on a fixed fee, with written acceptance criteria.
Ownership: Source code, documentation and credentials yours on payment. Ownership, not a license.
Accounts: Repositories, hosting and domain in your organization. We are members, never owners.
Exit: One of your people trained to build, deploy and run the software without us.

How we work: every commitment, with its limit

Six questions from teams whose vendor went quiet.

What should we do when a developer will not hand over the source code?

Three things, in this order:

Secure everything already in your name, starting with the hosting account, the domain and any repository you can reach, because those decide whether the product keeps running.
Then read the contract with counsel: whether you own the code usually depends on what was signed, not on what was paid, and we do not give legal advice on that part.
Meanwhile, list what you can recover without the vendor, since a running production server often holds more than you expect.

How do we avoid vendor lock-in on a software project?

By writing the exit into the contract before the work starts:

The source code, the documentation and every account belong to the client on payment, not under a license.
Repositories live in an organization you control, with the vendor invited as a member.
Deployments are scripted so that someone else can run them.
The vendor trains one of your people during the project.

Each of those costs almost nothing on day one and a great deal to obtain later.

What is a software escrow agreement?

A three-party arrangement in which the vendor deposits its source code with an independent escrow agent, and the client can obtain it if a defined event happens, such as the vendor going out of business. It protects against a disappearing supplier.

Its limit is that it deposits code, not knowledge. Ask whether the deposit is verified, meaning that someone checks it actually builds.

How long does a takeover assessment take?

It depends on the size of the system and on how much the previous vendor hands over, so the duration is fixed at the start rather than left open. For a typical business application it is measured in days, not months.

The longest part is rarely reading the code: it is getting the system to build and run on a clean environment, which is exactly the test that tells you whether you can continue without the vendor.

Should we rewrite the software or continue what exists?

Continue by default, and rewrite only on evidence. Existing code carries business rules someone already paid to discover, and a rewrite has to find them all again.

A rewrite becomes the cheaper option when the code cannot be built or deployed reliably, when there are no tests and every change breaks something else, or when the architecture cannot carry the requirements you actually have.

Can you take over a project built by a team outside Europe?

Yes. The origin of the team matters less than the state of what it left: a readable repository, a working build and some documentation make a takeover straightforward wherever it was written.

What we check early, for a system holding personal data about people in Europe, is where the data currently runs and which providers touch it, because a takeover is the right moment to bring hosting and access under your control.

And when the rescue turns into a new build?

Build and automate

Software, automations and AI hosted in the EU, sources in your name.

Closer to your case

Technical due diligence
You want a costed view of the whole system before committing to anything.

All services

Tell us what you hold. You will know what to secure this week.

20 minutes to list the assets, the open risks and the first thing to move to your side. If the project is better continued with the current vendor under a clearer contract, we will say so.

Tell us about your project

A 20-minute video call