A Commercial Deadlock Created Technical Risk

The client and its development vendor disagreed about whether months of user-interface changes belonged within a fixed-price contract. The vendor’s project manager had repeatedly treated the revisions as part of the job, but the vendor’s owner eventually concluded that the accumulated work exceeded the fixed price. The product still had not launched, an invoice remained unpaid, and nearly everything the client had purchased lived in systems administered by the vendor.

The immediate risk was not simply unfinished software. Contractual ownership was of little practical value when the client could not open the GitHub project, review the Jira or Trello history, edit the Figma designs, administer AWS, or see which outside services the application depended upon.

The Recovery Happened During the Dispute

The client made complete delivery of the project a condition of discussing payment. That preserved a useful alignment: cooperating with the transfer kept the payment conversation moving.

This window would not remain open indefinitely. Once the invoice was settled, abandoned, or handed to lawyers, ordinary account closures or staff departures could make recovery slower or incomplete. I treated the transfer as part of the negotiation, not as cleanup to begin afterward.

Recovering More Than a Code Snapshot

A replacement team needed the history of the product, not just a zip file containing the latest code. I recovered:

• The complete GitHub project, including every saved version and the notes explaining who changed what
• The Jira and Trello records documenting requests, decisions, defects, changes, and deferred work
• Editable Figma designs rather than screenshots that a new designer would have to reconstruct
• Specifications, contracts, correspondence, and other shared project documents
• Administrative access to AWS and the other accounts used to build and operate the application

The Jira and Trello history mattered twice. It told the incoming team what the product was supposed to do, and it preserved the record of scope changes at the center of the billing dispute. Without it, the client would have lost both engineering context and evidence.

Changing Passwords Was Not Enough

Modern products connect to many other companies. This one relied on services such as Stripe for payments, Plaid for financial connections, Intercom for customer communication, and a single-sign-on provider for login. Each connection could involve an administrator account, an API key, a secret stored in AWS, or a callback address controlled somewhere else.

I built an inventory first, then moved administrative ownership and replaced the credentials. That order mattered: changing the obvious passwords before finding the less-visible keys could leave the client with a false sense of control.

The product was not yet live, so no customer funds or production traffic were in motion. The challenge was completeness. One overlooked Stripe key, AWS user, automated deployment credential, or login setting could interrupt the next team — or leave a former vendor with continuing access.

The Client Regained Control Without Losing the Work

The vendor cooperated while the payment discussion remained active. Nothing was lost: the client obtained the code, its history, the design source files, the decision record, the cloud accounts, and control of the connected services. A replacement development organization could continue without first reconstructing the project from fragments.

The lesson is straightforward: when a vendor relationship breaks down, recover assets while both parties still have a reason to cooperate. Make a written checklist at the beginning of any outsourced project — GitHub, Jira or Trello, Figma, AWS, documents, administrator accounts, integrations, API keys, and service credentials. A file transfer is only part of the job; the handoff is complete when the client can see, administer, and secure everything the product uses.