Dev Shops: The Client Took the Code and Stopped Paying. Prevention and Recovery.

Software development has a receivables problem unique among services: the deliverable is infinitely copyable and, once handed over, unrepossessable. The cleaning company can pause service; the distributor can hold the next shipment; the dev shop that pushed final code to the client's production environment and transferred the repo has exactly one form of leverage left, and it is called asking nicely. Which is why this playbook is 70 percent prevention, because in this vertical, the contract and the deployment sequence are the collections system.

Prevention: three clauses and a sequence

The IP-transfers-on-payment clause. The single most important sentence in a development agreement: "All intellectual property rights in the deliverables transfer to the client upon receipt of payment in full; until then, all work product remains the property of the agency, licensed to the client for evaluation only." Standard, uncontroversial at signing, and it converts the final invoice from a request into a closing condition. Without it, in many jurisdictions and most practical situations, you delivered a gift and mailed a hopeful PDF after it.

Milestone releases with paired payments. Structure builds as 30 to 40 percent to commence, staged milestone payments on demonstrable increments, and a final tranche of 15 to 25 percent against production deployment and IP transfer. Each milestone's code releases when its payment clears. This caps your maximum exposure at one tranche, forever, and it surfaces a paying-problem client at milestone two, when your loss is small, instead of at handover, when it is total.

The staging-versus-production sequence. The client sees everything on your staging environment: full functionality, their data, their stakeholders demoing happily. Production deployment, repo transfer, and credential handover happen after the final payment clears, framed at kickoff as standard release procedure, because it is. Note the ethics and the optics both point the same way here: you are not holding hostage something they paid for; you are completing an exchange in its agreed order. (What you must never do, for both reasons, is reach back into a client's live production system to disable something after handover; that path leads to legal exposure and deserved reputation damage. Leverage lives entirely on the near side of the transfer.)

Recovery: when the final invoice has already gone quiet

If you are reading this with code delivered and $28,000 outstanding, the prevention section stings; skip to what remains. First, run the standard ladder with dev-shop specifics: the invoice tied to the acceptance email ("per your sign-off on the 14th"), because documented acceptance defuses the retroactive quality dispute that non-paying software clients reliably discover. Two silent emails, then the phone, then a different human, typically the business owner rather than the product contact who has stopped answering.

Second, inventory your remaining leverage honestly: warranty and bug-fix period (suspended in writing until payment), documentation and handover materials not yet delivered, your availability for the phase-two work they mentioned, and, if the contract has the IP clause, the fact that their production system is running unlicensed code, stated factually and once, in the formal notice: "Per section 8, IP transfer is conditional on payment in full; until resolution, the client's rights in the delivered work remain unperfected." That sentence, reviewed by a lawyer for your jurisdiction before sending, concentrates minds at funded companies wonderfully, because their next investor's counsel will ask about IP chain of title.

Third, structure before you escalate: a client who went quiet at the final invoice frequently has a cash problem wearing a silence costume, and a front-loaded written plan recovers what pride was hiding. If the plan is refused and the silence holds through a final notice with a date, the formal decision tree applies, with one dev-shop note: small claims and demand letters work unusually well against clients whose product is live and fundraising, and unusually poorly against ones who have already shut down, so read which one you have before spending money.

The pattern file matters here too: the client who disputed hours at milestone one, went quiet at milestone two, and requested a split at milestone three told you everything before handover, if anyone was keeping the record. Keeping that record, replies classified, promises dated, per-client history visible at each release decision, is what RevCollect does for a living (bias disclosed). But the vertical's real lesson fits in one line: in software, collections happens at contract signing and deployment sequencing, and everything after handover is negotiation with the leverage you remembered to keep.

FAQ

Can a dev agency legally withhold code for non-payment? Withholding undelivered work and unperfected IP per an explicit contract clause is generally defensible; sabotaging or disabling systems already in the client's possession is not. The clause and the deployment sequence, agreed upfront, are what make withholding clean.

What payment structure should a software agency use? 30 to 40 percent at commencement, milestone payments paired to staged releases, and a final 15 to 25 percent against production deployment and IP transfer. Exposure stays capped at one tranche.

The client claims the software is defective and refuses the final invoice. Now what? Anchor to the documented acceptance criteria and sign-off, offer a defined punch-list resolution with a deadline, and isolate any genuinely disputed amount while collecting the rest. Undefined quality objections that appear only at invoice time are a negotiation, not a defect report.

Should a small dev shop bother with lawyers for contracts? Once, yes: a reviewed template with the IP-on-payment clause, acceptance procedure, and milestone terms costs a few hundred to low thousands and functions as the collections system for every project after.