Taking Over a Half-Finished Project: How to Assess It First

It usually starts with an apologetic email. A freelancer has disappeared, a previous agency relationship has ended badly, or an in-house developer has left halfway through. There’s a deadline, a client who’s already frustrated, and a codebase nobody currently understands.

Taking over someone else’s half-finished project is one of the riskiest jobs in web development, mostly because it’s so tempting to quote before you really know what you’re taking on. This is how we assess one before making any promises.

First, get access to everything

Before anyone judges the code, make sure you can actually reach it. The list is longer than people expect:

• The code repository, with full history, not just a zip of the latest files
• Hosting, staging and production servers, plus the database
• The domain registrar and DNS
• The CMS admin, and any commercial plugin or theme licences
• Third-party services: payments, email, forms, analytics, APIs and their keys
• Design files, the original brief and any change requests agreed since

Missing access is the most common blocker in a rescue project, and sometimes the most expensive. A domain or a hosting account registered in a departed developer’s personal name can take weeks to recover. Find out now, not the day before launch.

Find out what “finished” was supposed to mean

Half-finished compared with what? Rebuild the scope from whatever exists: the original brief, the proposal, the designs, email threads, the client’s own list. Then compare it with what’s actually built. The gaps usually fall into three groups:

• Not started: features that simply don’t exist yet
• Started but broken: features that look done and don’t work, or only work in one browser
• Done differently from the brief: changes agreed somewhere along the way that nobody wrote down

The third group causes the most arguments later, so bring it into the open early.

Assess the code before quoting

Spend a fixed, paid amount of time reviewing the codebase before giving a price for completing it. The questions that matter:

• Can it be run locally and deployed reliably? If nobody can set up the project from the repository, that’s the first job.
• Is the structure sound? Consistent patterns can be finished. A patchwork of approaches often has to be partly rebuilt.
• How out of date is it? Old framework versions, abandoned plugins and unsupported dependencies add hidden work.
• Are there security problems? Exposed keys in the code, unpatched plugins, and admin areas without proper protection.
• How was it tested? Usually, it wasn’t. That affects how much you can trust the parts that seem to work.

Finish, fix or rebuild?

The assessment points to one of three routes:

• Finish it: the foundations are sound, and the work left is mostly missing features. This is the cheapest route when it’s available.
• Stabilise, then finish: the core is usable but needs fixing first, such as updates, deployment and security, before new work goes on top.
• Rebuild the problem parts: some sections are so tangled that fixing them costs more than building them again. Reuse the designs, content and whatever code is solid.

A full rebuild is sometimes the honest answer, but it shouldn’t be the automatic one. Throwing away working code because it isn’t how you’d have written it is expensive for the client.

Reset expectations with the client

A rescue project starts with trust already damaged. The most useful thing you can give the client is clarity:

• A written summary of what exists, what’s missing and what needs fixing
• A realistic plan and timeline, with the first milestone early so they see progress quickly
• A clear list of what isn’t included, especially the changes that were never written down
• Regular, short updates, because silence is what went wrong last time

Leave it better documented than you found it

Whatever route you take, finish with a README that explains how to run, deploy and update the project, and a list of every account and service it depends on. The next person to touch it, even if that’s you in a year, will be grateful.

If you’ve inherited a stalled project for a client, our project recovery and completion work starts with exactly this assessment. Send what you have through our project brief form and we’ll tell you honestly what it will take to finish.