# Software Project Rescue: Should You Fix, Rebuild or Change Developers? - Link: https://five-bricks.com/blog/software-project-rescue/ - Published: 2026-10-08T07:31:37+00:00 - Author: 5B_DEV Your launch date has slipped again. The team says the application is nearly finished, but you still cannot complete a customer journey without finding a problem. Before committing more money, you need a clear account of what works and what remains unfinished. Software project rescue begins by establishing what exists and what prevents it from working. Before approving more development or a complete rewrite, ask for evidence about the product’s current behavior, code, data and deployment process. The review may point to a few repairs or reveal that one component needs replacing. It may also expose problems with scope or the way work is being managed. Establish the cause before deciding whether to change teams. ## **Recognize the signs that a project needs an independent review** One missed estimate does not establish that a project is failing. More serious patterns include repeated regressions, demonstrations that cannot be reproduced and an inability to explain what is required for launch. Watch for these symptoms: * Features look complete individually but fail when used together. * The latest code cannot be built or deployed by anyone outside the current team. * Fixing one area regularly breaks another. * Progress reports describe activity without showing working customer journeys. * The business lacks access to essential repositories, hosting or service accounts. * Nobody can distinguish launch blockers from requests added after the original scope. Use these symptoms to frame the review. For example, if nobody else can deploy the application, ask the reviewer to identify the missing access, configuration or instructions. That gives you a specific problem to resolve. ## **Establish access and preserve the current state** Confirm that authorized business representatives can access the source repository, hosting, domain administration, database backups and relevant third-party accounts. Record which organization owns each service and who can grant access. Preserve a copy of the current code and data before substantial changes. Document what is running in production and whether it matches the repository. Have a developer verify that a backup can be restored in a separate environment. Coordinate any access changes so they do not interrupt the application. Replacing a team should include an orderly transfer of operational knowledge and credentials through secure channels. ## **Separate product problems from technical problems** ### **Requirements that keep changing** A team may be implementing features correctly while the definition of the product changes every week. More developers will not settle disagreements about what belongs in the first release. Define one release goal and write acceptance criteria for its essential workflows. Record new requests separately, with an explicit decision about whether each changes the release scope. ### **Code that cannot support reliable changes** Technical problems may include duplicated rules, missing boundaries between components, brittle integrations or inadequate tests around important behavior. The review should identify concrete examples and explain their impact on delivery. Ask the reviewer to reproduce a failure, trace its cause and show what would need to change. A generic statement that the code is “bad” is not enough to justify a rewrite. ### **A delivery process without usable feedback** Some projects have workable code but no dependable staging environment, release procedure or shared definition of completion. Developers cannot get quick feedback, and stakeholders see problems late. The recovery work may involve reproducible deployment, automated checks for critical journeys, smaller releases and clearer ownership. Evaluate whether the current team can adopt that process before assuming a complete team replacement is necessary. ## **Choose between repair, partial replacement and rebuild** ### **Repair when the foundation is usable** Focused repair is appropriate when the main product behavior is sound and problems can be isolated. Examples include an unreliable integration, missing permission checks or a customer workflow with a small number of reproducible defects. Agree on the behavior being repaired and how it will be verified. Avoid turning a recovery phase into an open-ended cleanup of every imperfect line of code. ### **Replace components when one area blocks progress** A difficult billing module or tightly coupled reporting feature may be replaced while the rest of the application stays in use. This reduces the amount of change customers experience at once, but it adds temporary integration work. AWS describes gradual replacement through the [strangler fig pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html), in which functionality moves incrementally to a new implementation. That approach can be useful when boundaries are identifiable and both implementations can coexist. It is not appropriate for every project. ### **Rebuild when essential requirements cannot be met economically** Consider rebuilding when the existing design cannot meet an essential requirement or when the estimated repair work exceeds the cost of a replacement. Both estimates must cover the same required functionality. Include data migration, integrations, existing user behavior and operational support in the rebuild estimate. A new interface can conceal substantial replacement work behind it. Money already spent should inform what can be reused, but it should not decide the next investment. Compare the expected remaining cost, uncertainty and time to a useful release for each option. ## **What a software rescue assessment should contain** Ask the reviewer to separate verified launch blockers from improvements that can wait. Each significant finding should explain what failed, how it was tested and what work would resolve it. The report should also explain which code and assets can be retained, what tests were performed and why the proposed recovery approach is preferable to alternatives. Estimates should make dependencies visible, particularly when access or documentation is incomplete. A reviewer who has only inspected the repository cannot confirm that production backups restore correctly. They also cannot establish how a live integration handles failure without testing it. The report should identify what remains unverified and how that affects the estimate. Suppose a client portal works for individual customers but exposes documents across accounts. Its access controls need repair, but the interface and document management features may still be usable. The assessment should explain those boundaries before recommending a complete replacement. ## **Change development teams without losing context** Before the handover, collect setup instructions, architecture notes, known issues, deployment steps and a list of external dependencies. Include the reasoning behind unusual decisions where it is available. Give the incoming team a bounded initial task. They should reproduce the application, verify one important workflow and make a small change through the intended release process. This reveals gaps in the handover before the team commits to a larger roadmap. Agree on ownership of releases during the transition. Two teams making uncoordinated production changes can create new failures while trying to resolve the old ones. If the product uses a CMS, our guide to [hiring CMS developers](https://five-bricks.com/blog/hire-cms-developers/) covers additional selection criteria. For a custom application, prioritize demonstrated experience with comparable systems and an evidence-based recovery proposal. ## **Set a recovery milestone you can verify** Separate the assessment from the implementation estimate when uncertainty is high. After the assessment, define a milestone that produces a usable result, such as a working onboarding and payment flow in a verified staging environment. Require a demonstration and acceptance checks for that milestone. Track unresolved defects and changes to scope alongside expenditure. This makes it easier to decide whether the recovery plan is working before committing to later phases. ## **Discuss your stalled project with Five Bricks** If your project is stuck, [contact Five Bricks](https://five-bricks.com/contact-us/) with a description of the product and the problems preventing launch or further development. Mention whether you have repository access. We can use that information to discuss what an initial review needs to cover. ## **Frequently asked questions** **Can another development team take over an unfinished app?** Yes, provided access and the available project information allow it. The incoming team should first reproduce the application and assess its condition before promising a completion date. **Is rebuilding always faster than fixing existing code?** No. Rebuilding includes recreating useful behavior, migrating data, reconnecting services and verifying the replacement. Compare both approaches using the same required functionality. **Can a live application be repaired while customers keep using it?** Often, changes can be tested separately and released incrementally. The plan depends on the affected components, data migrations and operational risk. Some work may require a planned maintenance window.