"software project over budget not finished what to do"

"Before you spend another dollar, you need an independent technical assessment — not from the vendor and not from your internal team if they're emotionally invested in the outcome. The three scenarios are: cut losses and rebuild smarter, inject new leadership and save the investment, or renegotiate with the vendor from a position of real information. You can't make this call without knowing what you actually have."

You Spent $2M on a Software Project. It's Still Not Done.

Eighteen months ago you had a vision, a vendor, and a budget. The vendor was enthusiastic, the timeline was clear, and the project was going to change the business.

Now you’re 18 months in, $2M deep, and the software still doesn’t work right. The vendor keeps finding new problems. The scope has drifted in ways you barely understood when they happened. Every meeting ends with a revised timeline and a new invoice. You don’t know if you’re three months away from done or if “done” is a fiction they’re selling you to keep the engagement alive.

I’ve seen this exact situation at companies that hired me to help get out of it. Here’s the honest assessment of where you are and what your options actually are.

First: Get an Independent Technical Assessment

You cannot make this decision with the information you currently have. You don’t know what percentage of the work is actually done (not “done done” by the vendor’s definition, but done by the definition of code that works reliably in production). You don’t know how much technical debt the vendor has accumulated in the name of speed. You don’t know if the architecture will support your actual requirements or just the watered-down version that emerged from 18 months of scope negotiation.

The vendor will tell you it’s 80% done. The 20% remaining is always the hard part. That’s not cynicism — it’s a pattern. The first 80% of a software project is building things. The last 20% is making things work together, handling edge cases, performance tuning, and fixing the architectural decisions that seemed fine at the time and aren’t. Vendors chronically underestimate this and rationally have every incentive to keep you engaged rather than tell you the project is in worse shape than it looks.

Hire someone with no stake in the outcome to review what you have. A technical due diligence on an in-progress project typically takes a week and costs $10–20K. That’s cheap compared to the decision you’re about to make.

The Three Real Options

Once you have an honest picture of where things stand, you have three paths:

Option 1: Cut losses and rebuild smarter

This is the right call when the codebase is unsalvageable — when the architectural decisions are so far wrong that completing this project would mean inheriting a maintenance nightmare, when the vendor relationship is toxic and would poison any recovery effort, or when the original requirements have changed so significantly that finishing this thing would mean completing something you no longer actually need.

Cutting losses feels expensive because you’re writing off the $2M already spent. But that $2M is gone regardless. The question is whether spending another $500K to finish this project makes sense — and the answer depends entirely on what you’d get. Sometimes the right answer is to take the knowledge you gained about requirements and architecture, go find a better vendor or build an internal team, and build it correctly in half the time.

Option 2: Inject new leadership and save the investment

This is the right call when the underlying codebase is sound but the project management has collapsed, the vendor’s technical lead has turned over, or the scope has grown so far beyond the original that nobody has a coherent picture of what’s supposed to be built.

A project this size going this wrong usually has a leadership problem at its core. Somebody on the vendor side stopped managing it well, or your side never had someone with the technical background to catch problems as they developed. Bringing in strong technical oversight — either embedded with the vendor or as an owner on your side — can save projects that have drifted rather than failed.

The signal that this is viable: the code actually works, just not completely. Engineers who look at it think it’s fixable. The vendor’s technical people (not their account team) believe a path to completion exists and can explain it specifically.

Option 3: Renegotiate from a position of real information

This is frequently available and almost never used because CEOs don’t have the technical knowledge to do it without help.

If the vendor has missed milestones, delivered incomplete work, or deviated materially from the original scope, you likely have contractual leverage you haven’t exercised. Vendors in over-budget projects are often carrying significant risk — they know the relationship is in trouble and they know that a legal dispute over a failed software project is expensive for everyone.

An independent technical assessment that documents what was promised versus what was delivered gives you real negotiating leverage. A vendor who knows you have this documentation will negotiate differently than one who thinks you’re relying on their word for what’s been done.

How to Tell If You’re Being Strung Along

The pattern of a vendor milking a failing project looks like this: every milestone slips by a little and is explained by something reasonable-sounding. Scope additions are proposed regularly, framed as necessary for the original vision. Questions about delivery confidence get answered with enthusiasm rather than specifics. The relationship stays warm even as the calendar and budget keep slipping.

Ask this question directly: “If we don’t change a single thing about this project — same team, same approach — when will it be done and how confident are you?” A vendor with a real answer will give you a date with specific reasoning. A vendor who’s stringing you along will give you another round of enthusiasm and a vague timeline.

If you’re in this situation, the smartest thing you can spend the next two weeks on is getting an independent technical review of where you actually stand. That’s exactly the kind of assessment a fractional CTO can run — without the politics of being inside the vendor relationship or inside your own organization. Book a call and let’s figure out what your real options are.