When A Client Ghosts Mid-Build: How Professional Web Developers Get Paid (And Hold The Code)

The Next.js developer whose client went silent three days after the 50% milestone payment, with 80% of the code already pushed to the client's GitHub, has a structurally different problem than the developer whose client cancelled outright. The kill-fee post handles the cancellation scenario where the client says "we're going internal" and the developer has clear termination grounds. This post handles the ghosting scenario where no cancellation was ever stated and the developer has already spent the physical leverage of withholding code.

The recovery sequence in the ghosting scenario is fixed and legal-leverage-based, not physical-leverage-based. The kill-fee post for the cancellation scenario covers the parallel post where the client makes the cancellation explicit; the framework here applies when silence is the only signal.

When silence becomes abandonment: the timeline that converts slow into breach

The first structural question is when the engagement is legally over. A client who has not responded for two weeks is "slow." A client who has not responded for sixty days is "in breach." The line between the two is what the dormancy clock establishes.

Per Jennifer Bourn's dormancy timeline for clients who disappear, the standard framework is:

"Day 7: send the first follow-up email. Day 14: combine email with a phone call. Day 21: try social channels and reference the dormancy clause in the engagement letter. Day 25: send a final-warning email. Day 30: send the formal dormancy letter naming the deemed-termination date. Day 42: send the cancellation warning. Day 45: send the official deemed-termination notice and invoice."

Source: Jennifer Bourn, "How to Manage Clients Who Disappear Mid-Project"

The Bourn framework is operational. Each step is documentable, each step has a fixed date relative to the last client contact, and each step creates an evidence trail for the eventual small-claims filing. The developer who runs the protocol arrives at Day 45 with a fully-documented record of the engagement transitioning from active to dormant to terminated.

The shorter the contract's dormancy clause, the faster the timeline runs. A 30-day dormancy clause means the engagement ends at Day 30; a 60-day clause means Day 60. The clause itself is what the dormancy letter at Day 30 references.

The code-already-in-their-repo problem

Standard ghosting advice (withhold the code, withhold the deliverables, refuse to release files until paid) assumes the developer still holds the work. The ghosting scenario this post addresses is the harder one: the code is already in the client's GitHub, deployed to their production environment, possibly already running in front of their customers.

Three things were true at the moment the developer pushed the last commit:

1. The 50% milestone payment was received (the trigger that justified the push at the time)
2. The remaining 50% is unbilled and the engagement is supposed to continue to completion
3. The client's silence had not yet begun: the developer pushed because work was ongoing

When the silence begins three days later, the developer faces an asymmetry: 80% of the code is in the client's environment producing value for them, and the developer is owed 50% of the contract (the unbilled portion) plus whatever abandonment fee the contract specifies. The physical leverage to withhold delivery is gone because delivery already happened.

The recovery has to work with what remains: the legal leverage of copyright ownership.

Copyright ownership after delivery: the legal lever you still hold

The default rule under U.S. copyright law is that the developer (as author of the work) owns the copyright until a written assignment transfers it. Delivery of files does not transfer copyright. Pushing code to a client's GitHub repo does not transfer copyright. The transfer happens only when the contract's IP-transfer clause activates, which most contracts condition on payment in full.

Per Linda Joy of Owen, Wickersham & Erickson, P.C., writing on the freelance digital-files question:

"Always include a provision making it clear that no usage rights are granted, and no digital files will be delivered, until full and final payment has been received."

Source: Linda Joy, Owen, Wickersham & Erickson, P.C., "Do you have to give your freelance client your digital files?"

The provision Linda Joy describes is the source of the developer's remaining leverage even after the code has been pushed. The physical files exist in the client's GitHub. The legal right to use those files does not exist until payment lands.

The two-part assertion the developer makes once the engagement is deemed terminated:

Assertion 1: Copyright has not transferred. The contract's IP clause conditions transfer on payment in full. The remaining 50% of the contract has not been paid. The transfer condition has not been met. The developer remains the copyright holder of the code in the client's repo.

Assertion 2: The client's continued use is unauthorized. Once the developer has asserted copyright via a written notice (the demand letter at Day 30+), the client's continued use of the code without paying is potentially unauthorized use of copyrighted work, which is copyright infringement.

The assertion is conditional. It applies because the contract conditioned IP transfer on payment. A contract that transferred IP at delivery (work-for-hire language with no payment condition) would not preserve this leverage. The contract scope-and-revisions post walks through the IP-transfer clause language that establishes this position.

The deemed-termination letter: what to send, when, and what it must say

The Day 30-45 deemed-termination letter is the document that converts silence into a contract-ended event. It does three things at once.

1. Establishes the termination date. The letter cites the dormancy clause in the engagement letter (or the dormancy timeline followed if no explicit clause exists) and names the date the engagement is treated as terminated. The date matters for the invoice deadline and the small-claims filing window.

2. Asserts the copyright position. The letter states that the developer remains the copyright holder of the code delivered to date, because payment in full has not been received and the contract's IP-transfer clause has not activated. The assertion is what creates the unauthorized-use posture for any continued client use of the code.

3. Names the recovery amount. The letter states the invoice amount due (completed work plus any abandonment or kill fee under the contract), names the payment deadline (NET 14 or NET 21 is typical for terminated engagements), and names the consequence of non-payment (small claims action with both contract breach and copyright infringement causes).

Sample letter language:

Re: Engagement Letter dated [Date] for [Project Name]

Per the dormancy clause of our engagement letter, Section [X], the engagement is hereby deemed terminated effective [Date] due to Client's failure to respond to documented written communications dated [list dates] regarding active deliverables.

Total amount due: $[X] comprising $[A] for completed work through the cancellation date plus $[B] as the Abandonment Fee per Section [Y] of our engagement letter. Payment is due by [Date, NET 14 from notice date].

Notice is hereby given that the code, documentation, and other deliverables created under this engagement remain the copyrighted property of Developer until payment in full of all amounts due is received. Client's continued use of the deliverables, including the code currently deployed in Client's GitHub repository at [URL], without payment in full constitutes unauthorized use of copyrighted work for which Developer reserves all legal remedies including statutory damages.

If payment is not received by [Date], Developer will file a small claims action naming both breach of contract and copyright infringement as causes of action.

Sincerely, [Developer]

Send the letter by certified mail with return receipt requested. The $4-$8 certified mail cost (per the LegalGPS contractor-ghosts framework) is what creates the evidentiary record that the client received the notice on a specific date.

Building the recovery invoice

The recovery invoice has three sections, parallel to the kill-fee invoice structure but with different math.

Section 1: Completed work through the deemed-termination date. The 80% of the contract value that was built and delivered to the client's GitHub. At the agreed rate, this is the bulk of the recovery. The 50% milestone payment already received gets credited against this amount. For a $24,000 contract where 80% was built and the milestone covered the first 50%, the completed-work line is $19,200, the milestone credit is $12,000, and the net for completed work is $7,200.

Section 2: Abandonment fee per contract. If the engagement letter contains an abandonment clause (a fee triggered by client silence or deemed termination), the fee applies. Typical abandonment fees range from 10% to 25% of the remaining unbilled contract value, calculated at the deemed-termination date. For the example above, 25% of the unbilled $4,800 ($24,000 contract minus $19,200 completed) is $1,200.

Section 3: Interest and recovery costs. Some contracts authorize the developer to recover collection costs (certified mail, demand letter preparation, small-claims filing fee). LegalGPS estimates these at $4-$8 for certified mail, $200-$500 for legal counsel demand letter, and $50-$150 for small-claims filing. If the contract authorizes pass-through of these costs, they appear as a separate line item.

The recovery invoice total in the example: $7,200 completed-work-net + $1,200 abandonment fee = $8,400, due NET 14 from the demand letter date. The $8,400 is small-claims appropriate in most U.S. jurisdictions (small claims limits typically range $5,000-$15,000 depending on state).

Small claims with a copyright angle

Standard small-claims advice for unpaid freelance work names "breach of contract" as the cause of action and the unpaid invoice as the damage. The recovery vehicle is the contract itself, the evidence is the engagement letter and the invoice, and the damage is the dollar amount.

When code is already in the client's GitHub, the developer has the option to name a second cause of action: copyright infringement. The dual-track filing strengthens the small-claims position for three reasons.

1. Statutory damages. Copyright infringement under U.S. law (17 U.S.C. §504) can carry statutory damages of $750 to $30,000 per work infringed, plus attorney's fees if the developer registered the copyright before the infringement began. Even when the developer has not registered the copyright (most freelance work is unregistered), naming the statutory-damages possibility raises the client's litigation cost calculus.

2. Separate cause from contract. A client defending the unpaid-invoice claim might argue the contract was vague, the deliverables were incomplete, or the scope was disputed. None of those defences apply to the copyright claim. The copyright claim depends only on whether the work was authored by the developer (yes) and whether the client is using it without authorization (yes, by definition once the demand letter has been sent and ignored). The dual-track makes the case harder to fight in pieces.

3. Pressure asymmetry. A defendant in a breach-of-contract small-claims case typically faces a fixed dollar amount. A defendant in a dual-cause case where copyright is named faces both the fixed contract damages and the open-ended copyright exposure. The client's incentive to settle before filing rises sharply.

The small-claims complaint names both causes:

Plaintiff [Developer] alleges: (1) Breach of contract by Defendant [Client] for failure to pay $[X] due under the Engagement Letter dated [Date], following deemed termination per the dormancy clause on [Termination Date]; and (2) Copyright infringement under 17 U.S.C. §§501 et seq. for Defendant's continued unauthorized use of Plaintiff's copyrighted code in Defendant's GitHub repository at [URL] following Plaintiff's written notice dated [Demand Letter Date] that copyright had not transferred due to non-payment.

The complaint reads as legally informed and reduces the chance the client treats the action as a bluff worth ignoring.

Contract clauses that prevent the next ghost

Each clause addresses a specific failure mode surfaced by the ghosting scenario. The dormancy clause sets the deemed-termination clock. The IP-transfer clause preserves the copyright leverage after delivery. The milestone-release clause prevents the developer from pushing 80% of code before the client has confirmed the work meets agreed criteria. The abandonment fee creates a contractual recovery amount above the completed-work invoice. The notice clause locks in the evidentiary form. The cost-pass-through clause shifts the recovery overhead to the breaching client.

The contract scope-and-revisions post walks through the broader engagement letter structure where these clauses sit. For the working contract template that combines the dormancy, IP-transfer, milestone-release, and abandonment clauses, the FreelanceDesk contract builder generates the document with dev-specific defaults pre-set.

References

• How to Manage Clients Who Disappear Mid-Project : Jennifer Bourn
• Legalities 33: Do you have to give your freelance client your digital files? : Linda Joy, Owen, Wickersham & Erickson, P.C.
• What to Do If a Contractor Ghosts You: Legal Steps : LegalGPS
• Ghosted as a freelancer? Here's what to do about it : Renee Fleck, Dribbble
• Ask HN: Freelancer's Dilemma : Hacker News