When the build stalls and nobody will say why
Before paying for another promise, establish what you actually have. A failed software project rescue starts with access to the source, the accounts, and the data, followed by a fixed-scope assessment of what runs and what can be kept. You get a written finding before committing to the next build. Sometimes the right decision is repair. Sometimes it is a restart.
When progress cannot be inspected
The deadline keeps moving by another week. Every demonstration runs on the developer's machine, but nobody can give you a working address. The repository or hosting account is out of reach. An invoice arrives before the work it is supposed to cover can be seen. These are warning signs to investigate, not proof of what has gone wrong.
A difficult project can have legitimate delays. The practical question is whether somebody can show the current state, explain the blocker, and identify the next testable result. If all you have is a changing completion percentage, you do not yet have enough information to decide whether to continue.
Gather what you already hold: the agreed scope, recent demonstrations, repository access, account ownership, and examples of what works or fails. Keep the original records. Avoid deleting the old environment or making a rushed handover the next person cannot reconstruct. The immediate objective is to make the project's state visible so the next decision is based on something firmer than reassurance.
An inspection you can use before buying a rebuild
A takeover assessment is a bounded piece of work with its own scope and written output. Agree the material to inspect and the questions to answer before starting. It does not quietly become permission to rewrite the application.
- Establish access and preserve what exists.
Identify the repository, hosting, domain, database, and service accounts. Arrange authorized access in accounts the business controls, preserve a copy of the source and data, and record missing access before changing a running system.
- Run the code somewhere safe.
Check whether another developer can build and run it from the repository. Separate working behavior from demonstrations that depend on an undocumented machine, a missing service, or data that cannot be reproduced.
- Inspect the data and the unfinished boundaries.
Check what records exist, whether their relationships make sense, and which workflows read or change them. Examine access control, integrations, deployment steps, and the gaps between the promised flow and the working one.
- Write down the finding.
List what is reusable, what needs repair, what needs replacing, and what remains unknown. Set out the alternatives and their dependencies. That assessment is a deliverable of its own, before you decide whether to commission a rebuild.
If important evidence is unavailable, the finding should say so. An unknown is a limit on the recommendation, not a blank to fill with confidence.
Keep what earns its place
Start with the data. Customer records, transaction history, and the relationships between them may remain useful even when the application around them does not. Preserve them, check their meaning, and establish which records can be trusted before designing a replacement. A database that starts successfully is not the same thing as a reliable business record.
The schema may also survive if it represents the business correctly. A working integration can be worth retaining when its behavior is understood and its access is under your control. Each part is judged on whether it can support the next usable version, rather than on how much was already spent writing it.
A half-finished interface is harder to value. Screens can look nearly complete while permissions, data validation, and the steps behind them are missing. Keeping the appearance can mean rebuilding everything that made it seem close to finished. The assessment needs to expose that distinction.
A rescue is sometimes more expensive than a restart. If retaining the old structure would cost more work than replacing it, say that plainly and preserve the useful assets. Past spending does not make the remaining work smaller.
Evidence you can inspect as the work moves
HDS is a principal-led practice. You can see who would actually be doing the work before deciding whether to hand over a difficult project. HDS uses review gates, verification, and accessible work records to make delivery accountable.
The internal AI platform includes code review + verification gates as first-class agents and audit-grade logging of every agent action. Those controls make work inspectable: changes have a record and verification is part of delivery. They do not remove the principal's responsibility for deciding whether a result meets the requirement.
The same expectation belongs in a restart: a working version you can access, clear acceptance criteria, and a record of what passed or remains unresolved. For the published delivery record, see platforms already in production.
Choose a useful slice you can verify
If you choose to proceed, start with a complete business action: a user signs in, does the required work, and saves a result that can be checked. That is a stronger milestone than finishing every screen while leaving the underlying behavior for later. Establish how that slice reaches a controlled environment and how its data is protected before expanding it.
The assessment informs the scope of custom software engineering. Access gaps, data repair, and dependencies must be visible in the proposal. Questions about how long a restart takes depend on those findings, and the software cost guide explains what drives the work.
Each following slice should leave you with something demonstrable and a clearer decision about what comes next. The objective is to regain control of the project, including the ability to stop with an understandable system and an orderly handover.
Questions when taking over an unfinished build
Will you work with the previous developer's code?
Yes, when it can be accessed lawfully, run, and understood well enough to maintain. The assessment decides what is usable. A different coding style is not a reason to discard working software. Missing source, unsupported dependencies, or behavior that cannot be reproduced may change the recommendation, and those findings belong in writing.
Who owns the code afterwards?
The recovery plan starts with source and service accounts under your business's control. Ownership of new work, access, and handover are agreed in writing before implementation. Existing vendor code and third-party components retain their own terms; the assessment identifies those constraints rather than promising rights nobody has checked.
What if the old developer will not give us access?
Start by listing the accounts and files you do control, along with what is missing. HDS cannot assess unavailable code or bypass another party's access controls. The initial finding can explain what is knowable from the available material and what depends on resolving access before work proceeds.
Can you promise to save the current build?
No. That would make the conclusion precede the inspection. A rescue can cost more than a clean restart, especially when repairing hidden assumptions takes more work than replacing them. The assessment exists to identify that situation while you still have a choice about the next commitment.
Tell us what was promised, what works, and what you can access.
Start with a free scoping conversation with Mike Hyams, the person who builds and supports the work.