Late software project: recover without starting over

The system was supposed to be live months ago. At every meeting, the date slips a little further. The vendor says it's almost done, but you can't see what's ready. The urge is to throw it all out and start over. That's almost never the best path, and it's never the first step.

Delays are more common than they seem. In April 2024, BCG surveyed executives across 25 industries, and almost half said more than 30% of their company's tech projects were late or over budget. Nearly one in five said results fell short of expectations more than half the time. What changes the outcome is the order of decisions. This guide lays out that order.

Signs the delay isn't a one-off

Every project runs a bit late at some point. The problem is when delay becomes the pattern. Watch out if:

• The date has changed more than once and nobody explains why.
• You only see screenshots and videos, never the product running.
• Every delivery fixes one thing and breaks another.
• The vendor can't say what's left, only that it's “almost there.”
• The person who was coding left and nobody knows where things are, like when the freelancer vanishes with the project.
• You don't have access to the code repository.

If more than one of these sounds familiar, the delay won't fix itself.

First step: everything in the company's name

Before any hard conversation, secure the access. If the relationship with the vendor goes sour, access is what holds the project together. Check:

• Code: the repository (GitHub, GitLab or Bitbucket) lives in a company account, with you as owner, not just a guest.
• Domain: the registered holder is the company's CNPJ (Brazilian tax ID). For .br domains, registration is handled by Registro.br.
• Hosting and cloud: account in the company's name, billed to the company card.
• Database and backups: where they live, who has access and when the last backup ran.
• Services tied to the product: transactional email, payment gateway, app stores, analytics tools.
• Passwords and keys: in a company password vault, not in a WhatsApp chat.

Without this access, every decision afterward is held hostage by a single person.

What to ask your current vendor

Be direct and ask for everything in writing:

1. A list of what's done, what's in progress and what hasn't started.
2. Access to the product running in a test environment.
3. Minimum documentation: how to install, how to deploy and which external services the system uses.
4. The cause of the delay, from their point of view.
5. What's left, with a date for each part.

How they respond already tells you a lot. A vendor who hands over the list, access and documentation is willing to solve it. A vendor who resists showing the code is hiding the real state of the project.

Audit: what really exists

An audit means reading the code, not the screens. It separates what works, what works badly and what only looks like it works. A good audit covers:

• Core flows: tested end to end, with real data.
• Security: starting with access control. In the 2025 edition of the OWASP Top 10, the list of web application risks maintained by the OWASP Foundation, broken access control is risk number 1, and 100% of the applications tested had some form of it.
• Data: database structure, consistency and backups.
• Maintainability: can another team understand and work on the code?
• Infrastructure: how the system is deployed, what it costs and what happens if it goes down.

The result is a list of what stays, what gets fixed and what gets rebuilt. That list becomes the price and the date.

Fix or rebuild: how to decide

Fixing makes sense when:

• The database is well modeled.
• The core flows work.
• Another team can read and maintain the code.
• The technology still gets updates.

Rebuilding makes sense when:

• Every fix breaks something else.
• You can't ship an update without fear.
• The data structure can't handle what the business needs.
• Fixing security means touching almost everything.

Often the answer is a mix. You can keep the data, the design and the business rules and rewrite only the parts that are stuck. Rebuilding one part doesn't mean losing what you already paid for: what the project taught you about the business still counts.

A new date in the contract, and how not to slip again

The new date needs a written scope. A date without scope is just another promise.

The same BCG study points to two practices that change the outcome. Early warnings on schedule and budget raised the success rate by up to 16 percentage points. Fully staffed teams, with no key roles vacant, performed 76% better than teams with important positions open.

In practice, that means:

• Seeing the product running often, not just in status meetings.
• Having someone in charge who warns you before things blow up, not after.
• Relying on a full team, not a single person.
• Cut scope to fit the date. Anything not essential to launch goes to the next queue.

How we do it at the Studio

A rescue starts with access and an audit. We read the code, test the core flows, check security and data, and list what stays, what gets fixed and what gets rebuilt. That list becomes a fixed price and a deadline written into the contract. Code, files and access stay in the company's name, and the dev team is the Studio's own.

We also know how to bring together what already exists instead of throwing it away. At LCX, a travel company operating in more than 10 countries in South America, one system per country became a single system, live in 29 days. And every system ships with an AI agent that runs daily, flags failures, suggests improvements and checks that the data makes sense. It's the early warning the delayed project was missing.

If your software project is late and you want to get it back on track without throwing away what you already paid for, the Studio's project rescue starts with an audit.