If your project has been 80% done for months, the problem is almost never the remaining 20% of features. It is that the last 20% was never actually defined. The visible work got built, and everything unglamorous behind it got deferred: error states, permissions, deployment, edge cases, the things nobody demos. The way out is not more effort in the same direction. It is to freeze the scope, take an honest inventory of what exists, write down what “shipped” means, and then finish in order of risk.
Here is how that works in practice.
Why 80% Is Where Projects Die
“80% done” is usually a count of features that exist in some form. It is rarely an estimate of work remaining, and those two numbers are wildly different.
The first 80% of a build is the part everyone can picture. Screens, flows, the happy path. It is well specified because it is easy to specify. You can look at it and tell it is progressing.
The last 20% is the opposite. It is the part nobody wrote down because nobody could picture it at the start:
- What happens when the payment fails halfway through
- What an admin can see that a regular user cannot
- What the app does when the third party API is down
- How data gets migrated when you change the schema
- What the deploy process is, and who can run it
- What happens on a slow connection, a stale session, a duplicate submit
None of that shows up in a demo. All of it is required to launch. So the project sits at “almost there” while the genuinely hard, genuinely undefined work goes untouched.
The Four Reasons We Actually See
Across takeovers, stalled projects fail for a short list of reasons. Usually more than one at once.
1. The Scope Never Stopped Moving
Every time the finish line got close, something got added. Individually each addition was small and reasonable. Collectively they reset the clock over and over.
The tell: you cannot name a date when the feature list was last agreed and unchanged.
2. The Person Who Had It In Their Head Left
A lot of projects are held together by one person’s undocumented mental model. When that person goes, whether a freelancer who stopped replying, an agency that moved on, or an in house developer who changed jobs, the project does not just lose capacity. It loses the map.
The tell: nobody can explain why a particular part was built the way it was.
3. The Last 20% Was Never Specified
This is the most common and the most fixable. The build was scoped as a feature list, not as a definition of done. So when the features existed, everyone assumed the end was near, and then discovered months of unscoped work underneath.
The tell: there is no written answer to “what has to be true for us to launch?“
4. The Foundation Cannot Carry the Finish
Sometimes the first 80% was built fast in a way that makes the last 20% disproportionately expensive. Authentication bolted on late, no test coverage on anything, business logic duplicated across a dozen files, a database design that cannot express what the remaining features need.
The tell: every new change breaks two things that were previously working.
A Realistic Plan to Get It Shipped
Step 1: Freeze the Scope in Writing
Not “we should stop adding things.” An actual written list, dated, with a line under it. Everything below the line goes to version two. This is the single highest leverage thing you can do, and it costs nothing.
A project that cannot be finished is often just a project that was never allowed to end.
Step 2: Inventory What Exists, Not What Was Promised
Go through the actual codebase and the actual deployed environment and record what genuinely works, what half works, and what was never started. Status reports and memory are both unreliable here. Only the code is honest.
Expect this to be uncomfortable. It is common to find that something reported as complete was never wired up, or that a feature works only for the one test account it was built against.
Step 3: Define “Shipped” as a Checklist
Write the conditions that have to be true to launch. Be specific and boring:
- A new user can sign up, verify their email, and log back in a week later
- An admin can do the three things admins actually need to do
- Payments succeed, fail gracefully, and are recorded somewhere you can audit
- The app is deployed by a repeatable process anyone on the team can run
- Errors are logged somewhere a human will actually see them
- Someone other than the original developer can run it locally
This list is usually shorter than people fear. Its value is that it turns “almost done” into a countable number of items.
Step 4: Sequence by Risk, Not by Ease
The natural instinct is to knock out easy items first because it feels like progress. Do the opposite. Start with whatever is most likely to reveal an unpleasant surprise: the deploy pipeline, the payment integration, the data model change you have been avoiding.
If something is going to blow up the timeline, you want to know in week one, not week nine.
Step 5: Ship Something Narrower
The fastest path to a launched product is almost always a smaller product. Cut to the version that solves one real problem for one real group of users, ship that, and add from there against actual feedback rather than assumptions.
A narrow thing in production beats a broad thing in staging, every time.
How to Tell If You Need Outside Help
Finishing internally is very possible when the foundation is sound and someone still understands the code. Bring in help when:
- Nobody currently on the project can explain how a core part works
- You have restarted the “final push” more than twice
- Fixing one thing reliably breaks another
- You cannot deploy without one specific person
- You are weighing a full rebuild mostly because the current code feels unknowable
That last one matters. Rebuilding is sometimes right, but it is chosen far more often than it is justified, usually because nobody has done the inventory in step two. A codebase that feels hopeless is frequently just undocumented.
What a Takeover Actually Looks Like
A good takeover starts with an assessment, not a quote. Someone reads the code, runs it, and tells you plainly what is there, what is salvageable, and what finishing it actually involves. You should come out of that with a written definition of done and a realistic sequence, whether or not you hire anyone.
Be wary of anyone who quotes a stuck project without reading it first. They are guessing, and the guess will be wrong in the direction that costs you.
If your project has been almost finished for longer than it took to get to almost finished, that is the signal. It will not resolve on its own, and the longer it sits the more context leaks out of it. Our software project rescue process starts by telling you honestly where the project stands, so you can make the call from facts instead of frustration.
