“The second-worst outcome is a finished product that doesn't work. The worst is paying for something that was never going to be finished.”
A founder three months into a six-month delayWhy Unfinished Freelance Projects Are So Common
Your freelancer didn't finish the project. Maybe they stopped responding, maybe they delivered something that clearly isn't done, or maybe they kept asking for more money and eventually went quiet when you didn't pay. Whatever the specific story, you're now sitting on a partial build, a ticking deadline, and the uncomfortable question of what to do next.
This is not rare. Freelance platforms are full of developers who can demo something impressive but struggle with the finishing work - the edge cases, the testing, the deployment, the small details that make a product actually ready to use. The demo looks great at 70% done. The last 30% takes as long as the first 70%.
The good news is that most unfinished projects can be rescued. The bad news is that the rescue process has its own traps, and stepping into the wrong ones will cost you more than the original project.
Before You Do Anything Else: Document What You Have
Your first task is to create an honest record of the current state. What has been delivered versus what was promised? Get the original brief or contract side by side with what's actually in the repository. For each feature or deliverable in the original scope, mark it as: done and working, partially done, or not started at all.
This document serves two purposes. It tells you what you're actually dealing with (not what you assumed was done based on conversations), and it forms the basis of any dispute resolution if you paid for work that wasn't delivered. Screenshots, commit timestamps, and Loom recordings of what actually works are more useful than email threads.
- List every feature in the original scope and its current status: done, partial, or missing
- Get a copy of all source code - even if it's incomplete - before any dispute escalates
- Check what's live versus what's only in a local development environment
- Record any known bugs or broken flows in the existing build
- Identify any third-party services that are set up but not fully connected
- Note what credentials and accounts you have access to versus what the freelancer controls
The Financial and Legal Side You Can't Ignore
If you paid in full before the project was finished, your options depend on how the contract was structured. Milestone-based payments with clear deliverables give you the clearest path to recovery - either through the platform's dispute process or a direct claim. Lump-sum upfront payments are harder.
Platform-based disputes (Upwork, Fiverr, Toptal) have their own resolution processes and often side with the client when deliverables are clearly documented. Direct hires are more complicated and may require a formal legal process if the amount justifies it. The practical advice: document everything now, even if you decide not to pursue a dispute. You may change your mind later.
Should You Try to Find the Freelancer or Move On?
If the freelancer is still reachable, it's worth one more structured conversation before giving up on them. Some developers go quiet because they're stuck, not because they've abandoned the project. A clear conversation about what's missing, a revised timeline, and a final milestone payment can sometimes unstick a stalled project.
The warning signs that moving on is the right call: the freelancer has been unresponsive for more than two weeks, they've asked for additional budget beyond the original quote more than once without a clear justification, or what they've delivered has fundamental structural problems that suggest they don't have the skills to finish it properly.
Week 1
Audit what you have, document all gaps, secure all access credentials and source code
Week 1 to 2
Attempt one structured conversation with the freelancer with a written scope and deadline
Week 2 to 3
If no credible commitment, brief a rescue team with your audit findings
Week 3 to 6
Stabilisation phase - new team reviews code, fixes critical issues, establishes clean workflow
From Week 6
Complete remaining features against revised scope, test thoroughly, deploy
What a New Developer Needs to Continue Your Project
Don't walk into a new engagement assuming the next developer can just "pick up where the last one left off." That framing creates unrealistic expectations and leads to another disappointing outcome. Every new developer needs to understand what they're inheriting before they can estimate what it will take to finish.
Give them the source code, the original brief, your audit of what's done versus what's missing, and access to any staging or production environments. A good team will come back with a clear picture of what they can deliver and what it will cost - based on what you actually have, not an optimistic guess.
How to Avoid This Situation Next Time
Milestone-based contracts with clear acceptance criteria prevent most of the common problems. Each milestone should define exactly what will be delivered, how you'll verify it's working, and what the payment amount is. Never pay for a milestone until you've verified the deliverable against the criteria in writing.
Require code to be committed to a repository you own from day one. Weekly progress calls - even 15 minutes - catch stalled work before it turns into three silent weeks. And insist on deploying to a real environment early, not just running locally on the developer's machine. If it doesn't deploy in week two, it won't deploy in week eight either.
When a freelancer didn't finish your project, the fastest path back isn't finding another freelancer and hoping for better luck. It's working with a team that has done rescue work before, knows what questions to ask before committing to a scope, and has the depth to handle whatever the original developer left behind. That's where Zovintra's Launch and Rescue service comes in - if you're stuck, let's take a look at what you have.
