A new developer may be able to finish your software if they can check what already works, get authorized access to what it needs and show a credible way to finish an important task. Ask for a small assessment first. A screen that looks finished may still stop before saving the result, and a copy of the code may be missing the instructions or services needed to run it.
If people already rely on a live version, agree who will keep it running while the assessment happens. You can decide how to support that version now and decide whether to replace it later.
What can you hand over to a new developer?
Ask for the version of the source code that was last used or tested, along with the instructions and dependencies needed to build it. Find out who controls the accounts used to deploy the software and connect it to other services. Identify where business records and backups are held and what your agreements let you share or modify. Access to a repository does not by itself establish those permissions.
Keep these questions separate. A team may be able to run a copy and still lack access to update the live version. Or it may have access to the hosting account but be unable to recreate the software from what was handed over. If the records would need to move, try an export the next system can actually use as a separate check.
What should the incoming team demonstrate?
Choose one job that matters to the business. Imagine service coordinators use an unfinished tool where a worker can submit a request, but nobody has demonstrated that a manager can approve it and retrieve the decision later. Ask the team to build a known version of the software and try that job in a separate, authorized test environment. Use invented records and disable real notifications, payments and other live actions. Keep the running system out of the test.
Watch the request go as far as it can, then record where it stops. If the manager can approve it but the decision disappears after reopening the request, the team has something specific to investigate. If a missing dependency prevents the team from starting the software, record that the workflow has not yet been demonstrated and name the missing piece. That evidence leaves a different next decision from a confirmed failure in the approval step.
A build shows that the team could assemble that version in those conditions. It does not establish the security or maintainability of the whole system, permission to deploy it, or readiness to operate it in production. Google's account of handing over operational responsibility illustrates that separate decision: its review covers dependencies and readiness, with training and improvements where needed.
Should you continue, repair part of it or replace it?
Compare each option against the same job and the work it will take to support the result. The UK government's purchasing guidance gives an example of comparing adaptation and new development in terms of needs, costs and the capacity to operate what you choose.
Continue
The team can build a known version, the existing workflow works in the test setup, and the missing step can be added without changing how the rest of the system works.
Repair part of it
The core workflow is usable, but one area such as deployment or an integration needs a defined repair. Ask how the team would test the repair before reusing that part.
Replace it
The options that keep the software cannot meet an essential requirement at an acceptable cost or risk. Plan how records and active work would move before switching.
If replacement looks right, decide separately how to keep current work moving. Running both systems for a time is one possible transition, with its own costs and responsibility for records.
What should the assessment put in writing?
Ask for a short record you can read with the people who use the software. It should say what the team demonstrated, what failed or could not be tested, which access or permissions are missing and what could interrupt current work. For each viable option, name the next stage, who needs to act and what you will check before approving further work.
For the example request tool, the next stage could be to trace why a recorded approval disappears, then show that a manager can return and see the decision in the test system. If you're comparing teams to do that work, see what to ask a custom software developer before choosing one.
Questions about taking over unfinished software
Is having the source code enough?
It gives the incoming team something to inspect. Check which version it represents, whether you can provide authorized access to what it depends on, and whether the team can build it and run an important task away from the live system.
When is a targeted repair enough?
Consider it when the core workflow works and the team can define and test a repair in one area. Ask what that change would leave unresolved and who could maintain it afterwards.
What should the assessment give me?
A short record of what worked in the test, what remains unverified, what is missing and what each option would require. Name who keeps any live version running and what you would approve next.
