--- title: Can someone take over a half-finished project? description: What I look at before agreeing to finish a technology project someone else started, and what makes the difference between a cheap rescue and a rebuild. date: 2026-09-23 updated: 2026-09-23 tags: [decision frameworks, projects, vendors] url: "https://joshdargie.com/blog/taking-over-a-half-finished-project" author: Josh Dargie --- A few times a year I get a call about a project that has stopped moving. A website, an internal tool, a network build, something with a deposit paid and a finish line that keeps sliding. The question is always some version of the same one: can you just finish it? Sometimes. Not always, and not always cheaply. What follows is roughly how I work out which one it is, partly because it is useful to know before you make the call. ## I say no more often than people expect Finishing someone else's work is not the easy option it looks like from the outside. You inherit decisions you did not make, in a structure you did not design, with no memory of why anything is the way it is. There are projects where the honest estimate to take over and complete is higher than the estimate to start again with what everyone now knows. Saying that out loud costs me work sometimes. I would still rather say it in the first conversation than three invoices in. ## The first thing I ask to see is the thing running Not a repository, not a plan, not a screen recording. Something working, in front of a real user, doing a task the business actually needs. That one request sorts most projects quickly. If a version exists and does two of the five things it needs to do, we are talking about completion, and completion is usually worth doing. If nothing runs anywhere after months of work, the project is earlier than the invoices suggest, and pricing it as "nearly done" would be a favour to nobody. ## Then: who holds the keys Domain registration, DNS, hosting, repository, app store accounts, the licence keys, the email address the whole thing was registered under. I check this early because it determines whether a handover is an afternoon or a project of its own. When ownership sits with the previous vendor rather than the business, the work of straightening that out comes before any new feature. It is dull, it is not what anyone wanted to pay for, and skipping it just moves the problem to the next person. I wrote separately about [who should own your business accounts](/blog/who-owns-your-business-accounts), and the short version is: you, always, from day one. ## The previous vendor is usually not the villain This is the part I want to be clear about, because "my last developer was terrible" is how a lot of these calls open. Most stalled projects I see were not sabotage or incompetence. They were an estimate given before anyone knew the requirements, followed by scope that grew a little each month, an approval that took six weeks, a key person moving to another account, and a client who was busy running their business. Nobody in that chain behaved badly. The project still stopped. I am not interested in building a case against whoever came before me, and you should be wary of anyone who is. Blame is not a deliverable, and a consultant who arrives keen to condemn the last one will speak about you the same way later. What matters is what exists, what it would cost to finish, and whether the original goal is still the goal. ## The three answers I usually land on Finish it as it stands. This is the outcome when the foundation is sound and what remains is work rather than rethinking. It is the cheapest ending and it is more common than the internet would have you believe. Finish something smaller. Often the plan grew well past the problem. Delivering the version that solves the original need, then stopping to use it for a few months, gets a business further than resuming a build nobody has questioned in a year. Keep the knowledge, rebuild the weak part. Sometimes the requirements and the design work are genuinely valuable and the implementation is the part that has to go, or the reverse. Very little of a stalled project is worthless, even when the code is. As for the money already spent: it is spent. It has no bearing on which of those three is cheapest from here, although it does have a lot of bearing on how the conversation feels. Deciding while you are still annoyed about the deposit tends to produce the expensive choice. ## What makes a rescue cheap Standard tools rather than something clever and bespoke. A README, or any writing at all about how it works. Account access in the business's own name. Someone on the client side who can explain what the thing is for without reading from the original proposal. Projects with those four are usually straightforward to pick up. Projects missing all four are not doomed, but they should be priced as discovery first, and any consultant who quotes a firm number before doing that discovery is guessing at your expense. ## If you are in this spot Gather what you have before you call anyone: access details, the original proposal or scope, whatever was last delivered, and a plain list of what the project was meant to do. An hour of that saves a fair bit of billable time on the other side, whoever you end up hiring. If it is a larger build, a short independent read before you commit more money is usually worth it. That is what a [second opinion](/blog/second-opinion-value) is for, and I have also written about [when a project is too big for the vendor you chose](/blog/project-too-big-for-your-vendor), which is a different problem with a similar shape. If you want someone to look at a stalled project and tell you honestly which of the three answers applies, [get in touch](/contact). I quote this work as a fixed fee, hourly or a retainer depending on the size of it, I do not resell anything, and the [assessment](/hire#assessment) is deliberately small so that the recommendation is the product rather than the beginning of a long engagement.