Can another development company finish or repair my existing project?
Arrange an authorised handover of code, accounts and documentation, preserve the current state and commission a bounded assessment. Have the incoming team reproduce the build and test important journeys. Compare repair, partial replacement and rewrite against evidence, then approve a staged plan with acceptance checks and ongoing ownership.
The key idea
Pay for a clear assessment before accepting a rescue promise. The useful output is an inventory, verified gaps and a practical next step.
Collect access without disrupting the running service
List source repositories, hosting, domain, database or other stored records, design files, mobile-store accounts and external services. Identify who controls each and what access the incoming team is authorised to use. Review the existing agreement and licences with the people responsible before transferring work. A zip file of screenshots is not a source-code handover.
Preserve a copy of the current project and relevant data using an agreed secure process. Record the running version and deployment date if known. Do not immediately rotate everything, change hosting and replace the code at the same time. Plan access changes so the business retains control without interrupting a live service or losing evidence of the current state.
Ask for a reproducible starting point
The new team should run the project in a controlled environment and explain what is required: supported runtime, dependencies, configuration and connected services. Record what starts, what fails and what cannot be checked because access is missing. If the deployed version differs from the repository, investigate that difference before estimating fixes.
Ask for a factual inventory: features demonstrated, important defects, absent requirements and uncertain areas. Avoid a blanket “the old code is bad” conclusion. NIST’s secure-development framework provides useful vocabulary for development practices and responsibilities; the assessment should translate relevant checks into project findings rather than claim a certification it does not have.
In practice · illustrative example
Choose the smallest working slice worth recovering
Imagine an unfinished customer portal with attractive screens but an unreliable request submission. Start by tracing that request from browser to staff, including the confirmation and error path. You may discover a useful foundation, a missing integration or an unimplemented process. A visual completion percentage cannot distinguish those cases.
Ask the recovery team to propose one reviewable milestone that restores a useful journey. Require a reproducible version, known access and an explanation of remaining gaps. Preserve the current working service while evaluating the next step. The goal is a decision supported by evidence, rather than an immediate promise to repair or rewrite everything.
Recover one complete journey before widening the scope
-
Collect the starting point
The team identifies the working version, access and external dependencies.
-
Trace one task
Inspect the customer action and the staff outcome together.
-
Deliver a bounded fix
A small milestone has clear acceptance and known exclusions.
-
Decide the next phase
Use the evidence to choose further repair or replacement.
Check complete journeys rather than a percentage
Choose the functions that make the product useful. For an example booking app, create an account, choose a valid slot, receive confirmation, view the staff record and cancel. Include Arabic and English content, errors and access restrictions. A screen existing does not mean its underlying operation is complete.
Write observable acceptance for each journey. Separate defects from changed requirements; both require work, but they explain the project differently. Include administrative actions and handover tools, not just the customer interface. If payments, messages or external APIs are involved, verify approved testing access and a safe way to reproduce failures. Do not use real customer records as casual demonstration data.
Compare repair, partial replacement and rewrite
Repair may be sensible when important flows work and the remaining issues are understood. Partial replacement can suit one brittle component without discarding the rest. A rewrite may be justified when core requirements cannot be supported reasonably, but it is a new delivery effort with migration and regression risks. Ask the supplier to show the evidence behind its recommendation.
Compare the same target outcome for each option. Include data migration, URL continuity, integrations, staff training and the period when old and new systems may overlap. Keep unknowns visible and avoid an exact completion promise based only on a brief code review. A confident estimate should explain assumptions, dependencies and how new findings affect scope.
Recover in stages the business can review
Choose a first milestone that closes a real risk: a reproducible deployment, a complete enquiry journey or a verified order flow. Define what the business will test and who approves it. Separate essential launch work from improvements that can follow. A staged plan should make progress understandable without pretending that every remaining risk has disappeared.
Specify change approval, issue tracking, source access and deployment instructions. Agree backup and rollback responsibility before altering a live system. If another vendor supplies part of the operation, identify who coordinates that dependency. The recovery plan needs a business owner as well as developers, especially where policy or content decisions caused earlier delays.
Prevent the same uncertainty at the next handover
Keep current documentation, account ownership and accepted test scenarios with the project. Record recurring charges and who maintains external services. Ask another authorised team member to follow the setup instructions and locate the important records. This is a practical check that knowledge does not live only with one developer.
Give staff short instructions for common exceptions and a clear support route. Close the project against demonstrated outcomes rather than a statement that it is “almost done.” The most useful rescue leaves the business with a working product it can understand, maintain and hand over again if needed.
A worksheet for your team
A recovery milestone you can review
Use a customer task your business urgently needs rather than a broad completion percentage.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Starting version | A version the recovery team can reproduce. | Record missing accounts or dependencies before promising delivery. |
| Useful milestone | One end-to-end journey with acceptance checks. | Review the staff outcome as well as the screen. |
| Remaining gaps | A clear list of exclusions and unresolved findings. | Use it to approve the next bounded phase. |
Keep every recovered milestone documented. Recovery should leave the project easier for a future team to understand than it was at the start.
Prepare for an evidence-based recovery assessment
- Authorised access, ownership records and a preserved starting state.
- Reproducible build with documented missing dependencies.
- Demonstrated journeys and a defect-versus-new-scope list.
- Comparable repair, replacement and rewrite options.
- Staged acceptance, rollback responsibility and usable handover.
Frequently asked questions
Can another company finish a project started elsewhere?
Often it can assess and continue the work, but the answer depends on access, rights, code condition and requirements. Start with a bounded assessment rather than a promise based on screenshots.
Should we rewrite everything when changing developers?
Not automatically. Compare verified gaps and maintenance needs with the risks of rewriting and migration. Ask for evidence supporting repair, partial replacement or a rebuild.
How can I tell whether a project is nearly finished?
Test the complete business journeys and list what remains for launch, operation and handover. A percentage is useful only when it refers to a defined scope and demonstrated acceptance.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
Sources checked:
Request a clear assessment before a recovery commitment
Share your project scope and available documentation with GateGold. We can discuss an authorised assessment, practical options and the checks for the next milestone.
