A Troubled or Half-Finished Software Project: 10 Early Warning Signs and a Rescue Plan

In brief: In a troubled software project the most expensive mistake is ignoring the problem and waiting with “maybe it will fix itself.” The early warning signs are usually clear: no progress can be shown, delivery dates keep slipping, the budget grows without control, communication breaks down, there is no working build that can be tested, and access to source code and accounts is closed to you. First drop the panic and the blame and measure the situation: clarify what works, what is missing, how much money and time have been spent and who holds the code and accounts. Then choose one of three paths: realign with the current vendor and continue, hand the project to another team, or (only if truly necessary) rewrite it. Both “let's rewrite from scratch” without assessing code quality and ownership, and “let's just wait a bit more,” are risky. This article is general information; for contract and legal matters consult your legal adviser.

Last updated: October 2026

The problem usually comes slowly, not suddenly

Troubled projects usually go like this: an optimistic timeline at the start; “we're working on it” messages in the first months; then delay; scope disputes; thinning communication; being told the budget is not enough and, finally, the question “the system is half done, who will finish what?” Intervention was possible at every stage.

In this section we cover recognizing the early signs, then what you should do, in order. If you are planning to start a new project, read our guide to choosing a software company, which prevents most of these problems in advance.

10 early warning signs

1. You are not seeing a working build

Weeks, even months, pass and you are not shown something you can click and try. “The infrastructure is being prepared” is normal for a while; but if you see no concrete progress in a reasonable time, it is a serious warning.

2. Delivery dates keep slipping

A single delay is normal; repeated delays with unclear reasons (“it finishes next week” said many times) suggest the work is not being managed.

3. The scope is constantly being “renegotiated”

Sentences like “that wasn't in scope” or “that's extra work” become frequent; there is no written scope or it is ignored. In a project without a clear scope, cost and time go out of control.

4. The budget is overrun and the reason cannot be explained

The money spent is out of proportion to the progress shown. Extra budget is requested but no detail of the work done or an estimate of the remaining work is given.

5. Communication breaks down

Response times lengthen, meetings are postponed, the contact person keeps changing or cannot be reached at all. Weakening communication is usually a precursor of other problems.

6. The team keeps changing

The people looking after the project change and you have to explain from scratch each time. Loss of knowledge lowers both speed and quality.

7. Bugs rise while new features do not progress

With each release, things that used to work break; testing is not done or the team only fights fires. This points to a lack of code quality and testing.

8. Source code, server and account access is closed

You do not know where the code is or whose account the server is in; when you ask for access you get evasive answers. This is a hostage situation that makes it impossible to hand the project to someone else.

9. “Everything is fine” but there is no proof

There are reports but no concrete output (screens, a test environment, records). Questions go unanswered or are met with the same generic sentences.

10. Your instinct says “something is wrong”

Even if you do not know software, you can notice inconsistencies in how the work is going. Take your instinct seriously and ask for concrete verification.

A rescue plan for the first 2 weeks

Days 1–2: Stay calm, collect evidence

• Gather the contract, proposal, scope document, payment records and correspondence in one folder.
• Write down how much has been paid so far and what has been delivered.
• Avoid blame and sudden termination decisions; first understand the situation. Talk to your legal adviser before taking steps that would breach the contract.

Days 3–4: Clarify ownership and access

Get written answers to these questions:

• Where is the source code (which repository)? In which account? Can you be given access?
• Whose name are the domain, server, database and third-party accounts (payments, email, maps) in?
• Is there a test/development environment, and where can a working build be seen?
• What are the technologies and versions used?

Without this information it is hard to move forward whichever path you choose. If possible, keep a copy of the code and a database backup (if the contract allows) in a safe place.

Days 5–7: Have a quick independent assessment done

Ask an impartial expert for a short technical assessment (audit):

• Which features work and which are missing? What percentage of the scope is really done?
• Code quality: Is it readable, tested and written with widely used technologies?
• Are there critical gaps in security and data protection? (It can be checked against the basic items in our security guide.)
• What is the estimated remaining work and time?
• Is the architecture suitable for growth?

The assessment lets you base the “continue, hand over or rewrite?” decision on data, not feelings.

Days 8–10: Confront the current vendor and realign

Hold a written, concrete meeting with the vendor:

• Ask for a real status report: what is done, what remains, the risks.
• Ask for a new, realistic timeline and a remaining-work list; tie milestones to payments.
• Say that you want to see a working build every week or two.
• Request code and account access.

If the vendor refuses these steps, that is information in itself.

Days 11–14: Decide

With the data in hand, decide on one of three paths (detailed below).

Three paths: Continue, hand over, rewrite

When deciding to “rewrite”

A rewrite is intuitively attractive, but it is often an underestimated job. Check these:

• Can working and valuable parts of the old system (business rules, data model, design) be reused?
• Is a rewrite really cheaper and faster than finishing the remaining work? (Ask for this in the independent assessment.)
• Is it possible to put the new version live with a small core (in an MVP spirit)? See our MVP roadmap article.
• How will your existing data move to the new system?

As a general rule: instead of rewriting the whole system, strengthening the core that produces value first and progressing in stages is often lower-risk.

Extra care when choosing the new team

A team taking over a project that has gone into trouble does a different job from a team starting from scratch:

• It must be able to review the code and documents and give an honest assessment of scope, time and risk.
• Instead of saying “we'll take care of everything,” it should first propose a short discovery/assessment phase.
• It should offer a working model that keeps ownership and access with you from the start.
• It should be able to describe similar projects it has taken over in the past.

For comparing quotes, our pricing models guide helps: in such a situation a short, fixed-price assessment phase followed by development approved stage by stage is usually the safest way.

Preventive steps for the next project

To avoid living through the same problem again:

1. Document the scope in writing, together with the “out of scope” items.
2. Tie payments to milestones; do not move to the next payment without seeing a working build.
3. Have the source code, domain, server and accounts opened in your own name from the start.
4. Ask for regular demos (every 1–2 weeks).
5. Progress in stages: MVP first, then expansion.
6. Put testing and security work in the scope.
7. Clarify the maintenance and support plan before launch. See our maintenance and SLA guide.
8. Set termination and handover terms in the contract.

A sample message for talking to the current vendor without breaking communication

A written message along these lines handles the situation calmly and clearly:

Hello [Name],

We would like to review how the project is going. As of [date], we expect a written status report by [date] that includes which parts of the scope have been completed, the remaining work and a realistic completion date.

We also ask for written information on: (1) the repository where the source code is held and access for us, (2) the owners of the domain/server/third-party accounts, (3) access to a working test build.

Could we schedule a meeting next week?

Before sending this message, check the relevant clauses of your contract and, if needed, your legal adviser.

Taking over and recovering projects with Aktaş Digital

We take over software projects that have been left half-finished or have run into trouble. The process goes like this: first we carry out a short assessment that reviews the code, architecture, security and missing scope; then we present the options of continuing, partial restructuring or rewriting with their rationale and a scope and cost breakdown. We split the work into stages, show working builds regularly and keep source code and account access with you. Our related areas: web applications, SaaS platform development, e-commerce solutions and business software.

To describe the state of your current project you can use our quote form or reach us from the contact page; we offer an NDA option for confidentiality.

Frequently Asked Questions

Do I need the former vendor's permission to hand the project to another company?

It depends on your contract and its source-code/intellectual-property clauses. If your payments are complete and the contract provides for code transfer, it is generally not a problem; but if there is a dispute, proceed with your legal adviser. That is why clarifying ownership clauses at the start matters.

Can I get back the money I paid?

This is a legal question and depends on the contract, the work delivered and the nature of the dispute. Collect evidence (correspondence, payments, scope documents) and consult a lawyer. A technical assessment report can also be useful in this process.

Who should assess code quality if I can't?

An impartial software expert or team who has not worked on the project. The assessment reviews code structure, tests, security, documentation and remaining work. Asking for it as a short, fixed-price engagement is common.

Is rewriting everything better?

Often no. A rewrite can be expensive and long; keeping the parts that work and prioritizing the core that produces first value is usually safer. If code quality and architecture are truly inadequate, a rewrite may be needed; settle that with an independent assessment.

What happens to my data if my relationship with the vendor has broken down?

Make sure you can get a copy of your database and files; clarify ownership of the production server and accounts. Having the backups with you is good practice even before the relationship breaks down.

How long does it take to recover the project in such a situation?

The assessment can take a few days to two weeks; recovery time depends on the state of the code, the remaining work and the path chosen. A definite duration requires the assessment first.

Conclusion

The gain in a troubled project is noticing early, measuring coolly and deciding on data. Take warning signs seriously, secure evidence and ownership, have an independent assessment done and decide on continue, hand over or rewrite with that data. The first thing you can do today: write down in whose name your project's source code, domain and server accounts are, and check whether you have access to a working build.