The engagement is nine months in. Some of it works. Demos have looked fine for a while, but nothing has reached the people who were supposed to use it, the answers about remaining timeline have become less specific rather than more, and the internal conversation has moved from when will this launch to whether it will. This page is about what to do next, in what order.
One thing worth saying immediately: this situation is common, and it is usually not the result of an incompetent vendor. Understanding why it happened matters, because the same mistake made twice is considerably more expensive than the first time.
Secure access first
Before any assessment, any difficult conversation, and any decision about the future, confirm that you control the assets. This is not an accusation against the vendor. It is that access is trivial to arrange while the relationship is cordial and can become slow, expensive, or impossible once it is not.
- 1
Confirm you own the source control organization, not merely a seat in the vendor's, and that an administrator on your side can add and remove members.
- 2
Take ownership of the cloud accounts and the billing attached to them, rather than being a user inside the vendor's tenancy.
- 3
Collect domain registrations, DNS control, SSL certificates, and any third-party service accounts bought on your behalf.
- 4
Get a current export of production data in a documented format, and verify you can actually read it.
- 5
Confirm in writing what has been delivered, what remains, and that the code and documentation are yours under the contract.
Understand what actually went wrong
The most common pattern is not poor engineering. It is a model priced against a specification, applied to work whose specification never existed in usable form.
The build proceeds. A developer reaches a question the document does not answer, and the answer is a full cycle away, so a reasonable assumption gets made instead. That assumption is invisible: the code satisfies the ticket, acceptance passes, and the demo looks right. Repeat several times a week for months and you have a system that is internally consistent, technically competent, and wrong about how the business works. Nobody lied and nobody was lazy. The structure made the outcome likely.
- Demos consistently succeed while real users never receive the software
- Requirements were signed off once, early, and never revisited against what was found
- The definition of done is a ticket closing rather than someone doing their job in the system
- Rework is arriving as change orders, which means the contract is now the adversary
- Nobody on your side can state what remains, only what has been spent
Recognizing this matters because it identifies what has to change. If the cause was structural, hiring a different vendor into the same structure produces the same result at a higher price, and you will have spent eighteen months learning it twice.
Assess before you decide
The strongest instinct at this point is to declare the work a write-off and restart cleanly. It is almost always the wrong first move, and it is worth noticing that it is the same instinct that produces failed rewrites generally.
What exists usually contains real value that is expensive to reproduce: a schema that encodes months of decisions about your domain, integrations that were difficult to negotiate with a third party, and business rules that someone extracted from your operations at considerable cost. That knowledge is worth more than the code around it, and discarding the code discards the knowledge with it.
| Area | The question | What a bad answer looks like |
|---|---|---|
| Data model | Does the schema represent the business correctly, whatever the code quality? | Entities that do not match how the business actually thinks about jobs, customers, or money |
| Test coverage | Is there anything that documents intended behaviour? | No tests, so no record of which behaviour was deliberate and which was accidental |
| Integrations | Do the connections to systems you are keeping work, and are failures handled? | Happy-path only, with no retry, no dead-letter handling, and silent data loss |
| Deployment | Can it be built and deployed by someone who did not write it? | One machine, one person, undocumented manual steps |
| Security and access | Are permissions modeled, and is there an audit trail? | Shared accounts, credentials in the repository, no record of who changed what |
| Business rules | Are the rules written down anywhere outside the code? | Logic that only the departed team understood, with no documentation and no tests |
This assessment takes two to five weeks, produces a written document you own, and is the cheapest step available. Its output should be a costed recommendation you could hand to any vendor, including the incumbent, and including us.
Keep, replace, or run both
Assessments rarely conclude that everything should be kept or that everything should be discarded. The useful outcome is a boundary.
- Keep the schema and the migration work, and rebuild the layer above it where the business logic is wrong
- Keep working integrations and replace the workflow that sits on top of them
- Replace one workflow at a time, running old and new in parallel until the new one is trusted
- Discard genuinely unsalvageable areas, but only where the assessment says so rather than by mood
Running old and new in parallel is slower and less satisfying than a clean cutover, and it is how you avoid a second failure. The business keeps operating while the replacement earns trust one workflow at a time, and the moment of maximum risk is never a single evening.
Changing the structure, not just the vendor
If the original failure was structural, the fix has to be structural. In practice that means changing what you are buying rather than who you are buying it from.
- Buy defined increments with fixed prices and acceptance criteria written before work starts, rather than capacity against a document
- Define done as a real user doing their real job in production, not as a ticket closing or a demo succeeding
- Put the people doing the analysis in the same conversation as the people writing the code
- Make stopping a supported outcome after any increment, so continuing is an active decision
- Require that business rules end up in tests and written decisions, so the next transition is a handover rather than an excavation
Our commercial interest in that list is obvious, since it describes how we work. It is also the list that would have prevented the situation this page is about, and every item on it is something you can require of any vendor.
Common questions
- Should we sue the vendor?
- That is a question for your counsel and not for us, and the answer depends heavily on the contract and on what was actually promised. What we would say is that recovery and litigation are separate tracks: secure your access and get an honest assessment of the asset regardless of what you decide commercially, because both decisions are better made with that information in hand.
- Is it faster to start over?
- Occasionally, and less often than it feels. Starting over discards the domain knowledge encoded in the schema and the integrations, which is usually the most expensive part to reproduce, and it restarts the clock on a business that has already waited a long time. The assessment exists to make that a decision based on evidence rather than frustration.
- Can you work with the code an offshore team wrote?
- Routinely, and usually it is the better path. Taking over an existing codebase is a normal engagement: read it, get it building and deploying reliably, add tests around the behaviour worth keeping, then change it in bounded increments. Unfamiliar or unfashionable code is not the same thing as unsalvageable code.
- Does this mean offshore development does not work?
- No. It works well for specified, bounded work against a stable definition of done, and a very large amount of good software is built that way. What fails is applying that model to software whose requirements live in the undocumented habits of the people doing the job, because the model depends on a specification that in that situation cannot exist yet.
- How much does an assessment cost?
- Typically $15,000 to $40,000 depending on the size of the system and the number of integrations, over two to five weeks. The output is a written analysis with costed options that you own outright and can take to any vendor. It is deliberately structured so that hiring us for the work afterwards is a choice rather than a consequence.