Unfinished Software Project Rescue

What problem does this solve?

Stalled projects rarely announce themselves either. Status reports stay green until the demo, milestones slip by two weeks at a time, and the sponsor discovers late that the screens shown in review were front-end mock-ups over an unfinished back end. By the time the project stops moving, three things are usually true at once: a large part of the budget is spent, the original developers are unavailable or disengaged, and nobody in the organisation can state precisely what works. That last point is the real problem - decisions are being made about a system whose actual condition is unknown.

The evidence is almost always mixed. A stalled project typically contains a reasonable data model and some genuinely finished modules alongside features that exist only as empty routes, a build that runs on one developer's machine, no automated tests, dependencies two major versions behind, credentials committed into the repository, and a deployment performed by copying files. Meanwhile the requirement itself may have drifted: the process the software was meant to support has changed, or a packaged product now covers eighty per cent of it. Judging the project by its code alone answers the wrong question.

The reliable warning signs, in rough order of severity, are: nobody can build the application from the repository on a clean machine; there is no environment other than production; test data and real data live in the same place; the scope exists only as a slide deck with no acceptance criteria; progress is reported as a percentage rather than as working features; a single individual holds all the accounts; and the plan for the remaining work is described as 'two more weeks' for the third consecutive month. Two or more of these together mean the schedule is fiction, and continuing to fund it without an assessment simply buys more of the same.

How the solution works

Stop the build, run an assessment, then choose a path. The assessment scores five dimensions with evidence rather than opinion: working software (what genuinely runs, demonstrated end to end), code and build (repository history, reproducible build on a clean machine, dependency and end-of-life status, security exposure), data (schema quality, real data volumes, export path), requirements (scope clarity, acceptance criteria, whether the process still matches), and access and knowledge (who holds domains, cloud accounts, repositories, keys and licences, and what documentation exists). Each dimension gets a 0-5 score and a short justification, and the pattern of scores - not the total - points at the path.

Three paths follow. Resume when the build reproduces, the data model is sound and the remaining scope can be written as acceptance criteria; the work then becomes a normal project with a fixed backlog. Rebuild the core when the data model or integrations are worth keeping but the application layer cannot be maintained - salvage what is proven and re-implement the rest behind the same interfaces. Stop and replace when the platform is out of support, the requirement has changed materially, or a packaged product covers it. Whichever path is chosen, custody comes first: source, data, domains, cloud accounts, keys and licences move into your organisation's name before further money is spent. When Swedish Technology can help: we run the scored assessment as a fixed-scope first phase, take custody, and can complete the build with a named team through our outsourcing model or hand the plan to your own developers.

1. 1
   Intake (trigger) Collect what exists: repository or code archive, the original scope or tender document, contracts and invoices, demo environments, credentials your staff hold, and the last three status reports. Agree a build freeze so the assessment measures a stable state.
2. 2
   Inventory (capture) Map environments, services, third-party dependencies, integrations and accounts. Build the access register - domains, DNS, cloud tenants, repositories, CI, app stores, licences, API keys - and mark each as held, uncertain or lost.
3. 3
   Evidence gathering (processing) Attempt a clean-machine build from source; run the application against a copy of the data; walk the database schema; check dependency versions against end-of-life dates; review authentication, secrets handling and logging; test whether a restore works.
4. 4
   Scoring and gap analysis (integration) Score the five dimensions with the evidence attached, then map the original scope against demonstrable features to produce an honest completion percentage and a gap list, separated into must-have, deferrable and no-longer-needed.
5. 5
   Decision and stabilisation (action) Recommend resume, rebuild-core or replace with ranged effort. Immediately stabilise regardless of path: custody transfer, independent backup with a tested restore, secrets rotated, a non-production environment created and basic monitoring added.
6. 6
   Completion plan and reporting (reporting) Deliver a backlog with acceptance criteria, a milestone plan tied to demonstrable working software, a risk register, and reporting that measures progress by accepted features rather than percentages.

Reference architecture

The assessment looks at five layers. Weakness in the lower layers is expensive to fix and often decides the path; weakness in the upper layers is usually just remaining work.

Deployment options: Assessment work is done against a copy of the environment, never against production. Rebuilt or completed systems are deployed where policy requires - UAE-region cloud, on-premise or air-gapped - with environments separated and backups under your own billing.

Key capabilities

Integrations

Rescues touch the same set of external systems; the direction column shows what has to move or be re-established during the rescue.

Industry use cases

Implementation approach

1. 1
   Week 0 - intake and freeze Gather code, scope documents, contracts and credentials; freeze further development so the assessment measures a stable state; agree who decides on the recommendation.
2. 2
   Week 1 - custody and inventory Build the access register, secure anything expiring, take an independent copy of code and data, and verify a restore before anything is modified.
3. 3
   Week 1-2 - evidence Clean-machine build attempt, run against copied data, schema walk-through, dependency and end-of-life check, security review, feature-by-feature demonstration.
4. 4
   Week 2-3 - scoring and options Score the five dimensions with evidence, produce the gap list against original scope, and write the resume / rebuild-core / replace recommendation with ranged effort for each.
5. 5
   Week 3 - decision gate A single meeting with the sponsor, IT and procurement to choose the path, agree the budget envelope and confirm what will not be built.
6. 6
   Week 3-4 - stabilise Environment separation, backups, monitoring, secrets rotated, dependencies patched where safe, and a build pipeline so future work is reproducible.
7. 7
   Week 4 onward - completion in iterations Two-week iterations, each ending with working software demonstrated against acceptance criteria; documentation and runbooks written as the work proceeds, not at the end.
8. 8
   Hand-over Repositories, accounts, documentation and training delivered to your team, or ongoing maintenance under an agreed service arrangement.

Security & deployment

Half-finished systems concentrate security debt: credentials committed to repositories, shared administrator logins, test data taken from production, no audit logging, dependencies well past their support dates, and debug endpoints left open. Rescue work therefore includes a baseline review before any user traffic is trusted - rotate every secret that was ever in source control or a chat message, separate environments so production data stops being a test fixture, put authentication behind the organisation's identity provider, patch the dependency stack in a controlled order, and enable logging that can support an investigation. NIST SP 800-218 (Secure Software Development Framework) is a practical checklist for the build pipeline, and ISO/IEC 27001 provides the access-control and supplier expectations that procurement usually needs to see. On-premise and air-gapped deployments follow the same steps with local mirrors and manual media handling.

Limitations & prerequisites

• An assessment describes condition and options; it cannot recover schedule or budget already spent, and it will sometimes conclude that the honest answer is to stop.
• If the repository is incomplete or the build cannot be reproduced, effort estimates for completion widen considerably - reconstruction work is difficult to price until it is attempted.
• Requirements that were never written down cannot be verified. Where the original scope exists only as slides or conversations, part of the rescue is re-specification, which takes calendar time and stakeholder availability.
• Salvaging a data model is only worthwhile if the data itself is usable; poor data quality, mixed test and production records or missing history can outweigh the value of the schema.
• Out-of-support platforms, expired third-party licences or abandoned libraries can make 'resume' impossible regardless of code quality.
• Completion estimates depend on the availability of your own subject-matter experts for acceptance decisions; rescues stall a second time when nobody on the business side can sign off features.
• We do not provide legal opinions on contractual disputes with the previous supplier; we provide the technical evidence your counsel and procurement team need.

Decision table: resume, rebuild the core, or stop

Read this by row. A pattern of signals in one column - not a single bad finding - indicates the path.

The middle column is the most common result in practice, and the least often proposed - salvaging the data model and integrations while re-implementing the application layer usually beats both extremes.

FAQ

Related topics & solutions

• Our Software Vendor Disappeared: What Should We Do?
• Emergency Software Vendor Takeover: How It Works
• Failed ERP Implementation Rescue (Odoo, SAP, Oracle)
• Outsourcing Services
• SAIF ÔÇô Cybersecurity
• Document Management & Correspondence System
• Octopus WMS
• Request a Demo