Picking up a project left half-finished: where to start

The project is at 80%. It has been there for three months. The person who carried it has left, or the tool can no longer fix anything without breaking something else, or you simply stopped believing in it.

This situation is ordinary and it can be dealt with. What makes it hard is not knowing where to start, and the fact that every week of delay adds to the feeling that the work already done is lost.

It is not. Here is how to proceed.

Establish what you actually hold

Before any technical consideration, four things decide whether the project can be picked up and at what cost.

The code. Is it in a repository you can open with your own credentials? Generation tools support continuous synchronisation to a repository you control, provided it was switched on. If the project lives only in someone else’s account, that is the first thing to sort out.

Service accounts. The database, email delivery, payments, the domain name. Each belongs to an email address. If that address is a departed person’s, access can be recovered, but it takes days and sometimes weeks.

The secrets. The keys that make the application work are often held in the generation tool and nowhere else. Without them nobody can run the project, even with all the code.

What works today. A live application with real users is not picked up like a project that never went into service. In the first case there is data to preserve.

This list takes an hour to compile and it completely changes any estimate. Do it before asking anyone for a quote.

Why projects stall at 80%

Three causes recur, and none of them reflects on whoever started.

The tool reached its limit. A generation model works on what it can hold in view at the moment you talk to it. The bigger the project, the less of it fits. It ends up contradicting an earlier decision, rewriting a part that worked, and introducing an inconsistency. The next fix treats that inconsistency as a new fact and produces another. Every round adds code and widens the blast radius.

The remaining 20% are not the easy part. A demonstration sets aside everything that does not serve the demonstration: real access rights, users doing unexpected things, what happens when an outside service does not answer. That remainder holds most of the difficulty.

The code has duplicated. The GitClear study of more than 200 million changed lines between 2020 and 2024 shows copy-paste rising from 8.3% to 12.3% while refactoring fell from 24.1% to 9.5%. Translated: the same rule lives in five places, and changing it means finding all five.

What a handover looks at first

Order matters, because some defects have irreversible consequences and others merely financial ones.

First, anything exposing data: access rules, keys left in the browser, uploaded files reachable without authentication. Broken access control is the leading application risk category according to OWASP, and data that has left cannot be recalled.

Next, whatever prevents delivery: accumulated inconsistencies, two ways of doing the same thing living side by side, the parts nobody dares touch.

Only then, the missing features. Adding them onto an unstable base costs more than stabilising first.

Pick up or start again

The question deserves an honest answer, and it is not always the one you expect from a supplier.

Picking up makes sense when the screens match what you wanted, when users already rely on them, and when the code, however untidy, remains readable. That is the most common case.

Starting again is justified when the project never went into service, when the need has shifted since, and when the handover would cost more than a rewrite. It happens, and saying so is part of the job.

Either way, what was produced stays useful: the screens serve as a specification, and a specification validated by use beats a requirements document written without seeing anything.

What you get back at the end

A serious handover leaves behind more than a working application: a repository in your name, a written inventory of your access, and the minimum documentation letting a third party take over.

We also leave written markers in the code, aimed at developers and AI tools alike, so the structural decisions are found rather than contradicted. The goal is that you can carry on yourself for simple changes.

How long it really takes

The question always comes, and an honest answer means separating three stages.

The assessment. A few days on a modest application. It produces the list of what works, what exposes data, what is missing, with a cost per batch. This stage is billed separately and the document stays with you, even if you take the rest elsewhere.

The repair. This is the part that varies most. Closing broken access and moving exposed keys is measured in days. Cleaning up heavily duplicated code is measured in weeks. The difference depends less on the number of screens than on how consistent what was produced turns out to be.

Resuming development. Once the base is sound, the pace returns to normal, in the order of a few days per feature.

The point to remember: the first stage is enough to decide. You do not need to commit to the whole thing to know where you stand, and a supplier demanding a global commitment before any diagnosis is selling a rebuild rather than a handover.

What we do

We read the code as it is, with no judgement on how it was produced, and hand you the assessment in plain language: what works, what is exposed, what is missing, and what each batch represents.

You choose the scope, you get a fixed quote, and the work arrives in batches you can see progressing. You are not obliged to handle everything, nor to continue with us afterwards.