The true cost of a bad development partner

01Where the money actually goes

The figures below are directional rather than precise - every situation differs - but the relative magnitudes are consistent across engagements that go wrong. The pattern is that the recoverable costs arrive long after the vendor relationship has ended.

02Rework is the largest single item

Rework is driven less by developer skill than by requirement quality and feedback latency. Code built against a misunderstood requirement is a total loss regardless of how well it was written, which is why specification discipline matters more than any individual engineer's ability.

The compounding version is worse. Code without tests cannot be refactored confidently, so each subsequent change is riskier and slower than the last. Teams reach a point where the safest option is a rewrite, and the rewrite costs more than the original build because now there is production data and live customers to preserve.

• No automated tests: every change becomes a manual regression cycle.
• No documentation: every change starts with archaeology.
• Inconsistent patterns: new engineers cannot predict where anything lives.
• No CI: integration problems surface late, when they are expensive.

03Key-person risk and knowledge that never got written down

Bench-and-swap staffing models produce systems that only one or two people understand. When those people rotate off - and they will, because the model rotates people - the knowledge leaves with them. What remains is a codebase that works and nobody can explain.

The cost of reconstructing that understanding is substantial and almost always borne by you, not the vendor. Budget four to eight weeks per engineer to reach productive understanding of a non-trivial undocumented system, and accept that some behaviour will only be discovered when it breaks in production.

04Exit costs, and how they are created at signature

The cost of leaving a vendor is decided at the start, in terms nobody focuses on because the relationship is new and optimistic. Vendor-owned repositories, vendor-owned cloud accounts, vendor-controlled CI and unclear IP assignment each convert a straightforward transition into a negotiation.

The good news is that this is entirely preventable at zero cost. Client-owned repositories and cloud accounts, IP assignment on payment, and a contractual transition obligation cost nothing to agree at signature and are extremely expensive to obtain later.

• Own the git repository and cloud accounts from the first commit.
• IP assignment on payment, covering code, designs and infrastructure-as-code.
• Documentation and runbooks specified as contractual deliverables.
• A defined transition period the vendor must support.
• Credentials and DNS under your control throughout.

05Catching it early

Bad engagements produce signals well before they produce visible failure. The difficulty is that early signals are easy to rationalise while the relationship still feels productive and everyone is busy.

The most reliable early check is whether a competent engineer outside the vendor can read the codebase and explain how it works. If that is difficult at month three, it will be impossible at month eighteen. Commission an independent review early, while the cost of correcting course is still small.

• Velocity that looks fine while user-visible progress stalls.
• Every estimate landing exactly on the sprint boundary.
• Bugs in areas that were 'finished' several sprints ago.
• Resistance to an independent code review.
• Growing dependence on one individual to explain anything.