Short answer
For an unfinished or undelivered software project, we first document the real situation: code and account access, installability, open work and risks. Then we compare continuing, partial renewal and rebuilding on the same criteria and propose a phased completion plan.
Establish the actual state
We check source access, reproducible setup, data structures, open work and the last working release. Completed screens do not prove that an end-to-end workflow is ready.
Compare recovery options
Existing business logic, testability, maintenance effort and migration risks inform the decision. A rebuild is not automatically the best option for an older codebase.
Handover deliverables
A technical status summary, access inventory, risk register and staged completion plan make the next steps reviewable. Initial delivery should have observable acceptance criteria.
What to share
Describe repository access, documentation, missing workflows and provider handover arrangements. The assessment then clarifies recovery options, priorities and a staged completion plan.
When a takeover is not suitable
If access to the source code and basic accounts cannot be obtained at all, starting afresh may be necessary instead of a takeover. Contracts and legal disputes are outside this service; the technical status document can help in that process but does not replace legal advice.
How we work
Access and the code repository are verified, and we try to install the application in a clean environment. A status summary, risk list and options are written up. A phased plan is made for the chosen path; the first delivery is tied to an observable acceptance criterion such as setting up and verifying one core flow.
Frequently asked questions
The questions we hear most often before taking over an unfinished project.
Can you take over if I do not have access to the source code?
Not without the source code. The first step is to confirm that the repository, domain, server and third-party accounts belong to you and are accessible. If anything is missing, we plan together how to recover it.
What do you do if we are in a dispute with the previous developer?
We do not assess contracts or legal disputes. We document the technical state neutrally, and that document can help during the handover.
Do we have to rewrite everything?
Usually not. We weigh the value of working flows, cost of change, testability and data portability together. Our decision guide "Should you fix existing software or rebuild it?" explains the reasoning.
How long does the first assessment take?
It depends on the size of the codebase and how quickly access is provided. Once access is in place, we state in writing how long the technical status summary will take.
