Skip to main content
Freelancing

The Professional Web Developer's Kill Fee: What To Charge When A Client Cancels Mid-Build

Updated 11 min read

TL;DR

When a client cancels a web build mid-project, the developer is owed three separate amounts: payment for work already completed, the kill fee on the remaining contracted value, and the developer's leverage of unpushed source code until both invoices clear. Per ClauseShield's phase-tiered model, the kill-fee structure is decreasing: 50% of remaining value in discovery/planning, 35% in production, 25% in revision/delivery. The 'we're going internal' cancellation is termination-for-convenience and triggers the full kill fee, not termination-for-cause. Sample clause language plus the invoice line-item structure for the cancellation invoice.

The React developer six weeks into a Webflow rebuild when the client says "we're going internal" is owed three things, not one. The completed-work invoice for actual code through the cancellation date. The kill fee on the remaining contracted value at the phase-tiered percentage. The leverage of unpushed source code and unfinished design-system handoff until both invoices clear.

This post is the calculation framework. Per ClauseShield's March 2026 analysis of kill-fee structures:

"A kill fee is a predetermined payment that the client owes you if they cancel a project before completion. Without a kill fee clause, the consequences of cancellation fall entirely on you."

Source: ClauseShield, "Kill Fees: Getting Paid When Projects Get Cancelled" (March 8, 2026)

The structural problem at the heart of the burn scenario is the developer who entered the engagement without a kill-fee clause and is now negotiating ad-hoc compensation with a client who has decided to leave. The clause is what converts the negotiation from "what would you like to pay me?" to "what does the contract say you owe me?"

What a kill fee actually is, and why it is not a penalty

Per Adrien at Timescanner's freelance kill-fee analysis:

"A kill fee represents compensation for the capacity you committed and the opportunity you turned down, not a penalty."

Source: Adrien, Timescanner, "Why your contract needs a kill fee"

The reframe matters because clients who hear "kill fee" often read it as punitive. The legal and business reality is the opposite. The developer committed twelve weeks of capacity to the client. That capacity was unavailable to other prospects during those twelve weeks; the opportunity cost is real. When the client cancels at week six, the developer's capacity for the remaining six weeks is theoretically free again, but the prospects the developer turned down in weeks one through six are gone. The kill fee compensates for the irrecoverable portion of the committed capacity.

The phase-tiered model uses decreasing percentages because the opportunity cost is highest at the start of the engagement (the developer has just turned down the most prospects to commit to this one) and decreases as the engagement progresses (the developer has begun to free capacity through completed work that invoices at the normal rate).

The phase-tiered model: how to calculate what you are owed at each stage

Per ClauseShield's phase-tiered framework:

  • Phase 1 (discovery and planning): kill fee is 50% of remaining unbilled contract value
  • Phase 2 (production and development): kill fee is 35% of remaining unbilled contract value
  • Phase 3 (revision, QA, and delivery): kill fee is 25% of remaining unbilled contract value

The percentages apply to the remaining unbilled value, not the total contract. The completed-work invoice covers work already performed at the agreed rate; the kill fee covers the contracted-but-not-yet-performed remainder.

Worked example for the burn scenario. A $24,000 twelve-week React-to-Webflow rebuild, structured as a 50% deposit ($12,000) at kickoff and the remaining 50% billed in stages. Cancelled at week six (mid Phase 2). Three calculations:

Calculation 1: Completed-work invoice. Six weeks of work at the agreed rate. At $2,000 per week, that is $12,000. The deposit covers this exactly; no additional invoice is needed for the completed work.

Calculation 2: Kill fee on remaining value. The remaining unbilled value is $12,000 (the second half of the contract that was not yet billed). At the Phase 2 rate of 35%, the kill fee is $4,200.

Calculation 3: Total owed at cancellation. $4,200 kill fee, separately invoiced, referencing the contract clause. The deposit covers the completed work; the kill fee covers the remainder.

The same scenario at a different phase produces different math.

Cancelled at week two (Phase 1 discovery): kill fee is 50% of $22,000 remaining unbilled = $11,000. Two weeks of completed work at $2,000 per week is $4,000, fully covered by the $12,000 deposit (with $8,000 of deposit unused). The deposit structure matters here. If the deposit is upfront retainer, the unused $8,000 is returned to the client and the net cancellation invoice is $11,000. If the deposit is non-refundable engagement fee, the developer retains the full $12,000 plus invoices $11,000, for a total recovery of $23,000.

Cancelled at week ten (Phase 3 delivery): kill fee is 25% of $4,000 remaining unbilled = $1,000. Ten weeks of completed work at $2,000 per week is $20,000. The deposit covers the first half; the second-half billing through week ten depends on the milestone schedule. Net depends on what was billed in the interim.

pro tip

The percentages are decreasing, not escalating. A common misreading of phase-tiered kill fees is to assume the percentage goes up as the project progresses, on the logic that more has been invested. The opposite is correct. As the project progresses, more of the developer's work has already been invoiced at the normal rate, so the kill fee on remaining value drops. The 50/35/25 structure mirrors the opportunity cost arc, not the work-completed arc.

When a client "goes internal," that is termination-for-convenience

Some clients argue that hiring an in-house developer mid-project amounts to a kind of breach by the freelancer ("we needed someone full-time, you weren't available enough"). The argument does not hold legally and does not affect the kill fee.

Termination-for-cause requires demonstrable breach by the developer. The contract names specific obligations the developer is bound to perform: deliver milestones by named dates, code that meets agreed acceptance criteria, behaviour consistent with professional standards. If the developer missed those obligations, the client has grounds to terminate without kill-fee liability. If the client cancels because they prefer a different developer, want to reduce cost, or have changed strategic direction, that is termination-for-convenience and the kill fee applies.

"We're going internal" is the most common termination-for-convenience scenario in freelance web development. The client has not been wronged; they have changed direction. The kill-fee clause was written to compensate the developer for exactly this category of cancellation, where the freelancer performed correctly and the client made a unilateral choice to exit.

Code custody and the developer's leverage before final handoff

The kill-fee clause is the legal protection. Code custody is the practical leverage that makes the legal protection collectible.

For repo-based projects (React, Next.js, Vue, Angular, Node backend), source code that has not been pushed to the client's repository remains in the developer's local environment and the developer's private repo. The contract clause should name code as "transferred upon payment in full." The legal effect is that the developer retains IP in the unpushed code until both the completed-work invoice and the kill-fee invoice clear. A client who wants to take the partial code base internal must pay both invoices first.

For Webflow projects, the leverage structure differs. Webflow projects live in the Webflow platform under the developer's workspace until the developer transfers the project to the client's workspace. The transfer is a manual step the developer controls. The contract clause should name the project transfer as "completed upon payment in full of all amounts due under this Agreement, including any kill fee invoiced under the Cancellation clause." Until then, the client cannot take the project internal because the project is in the developer's workspace.

For no-code or low-code builds (Webflow, Framer, Bubble, WordPress with a private staging site), the leverage is the staging-to-production handoff. The developer's staging URL is functional but is the developer's environment. The client's production URL requires the developer to deploy. The deployment step is the gate; payment is what releases it.

The deposit-already-spent math

The most-asked question in the burn scenario is "what happens to the deposit?" The answer depends on whether the deposit covered specific completed work or was a flat upfront retainer against the whole project.

Case 1: Deposit as upfront retainer. The 50% deposit was billed at engagement start before any work was done. It functions as a credit applied to the first half of work as it gets completed. At week six of a twelve-week project, the deposit is fully consumed by the six weeks of completed work. The cancellation invoice is the kill fee only, not the kill fee plus completed work.

Case 2: Deposit as non-refundable engagement fee. The contract names the deposit as a non-refundable engagement fee that exists independently of the work performed. The deposit is the developer's guaranteed minimum regardless of cancellation timing. The cancellation invoice is the kill fee plus any completed-work that was not pre-paid by the deposit. The total recovery is higher in this structure but the structure is harder to negotiate at signing.

Case 3: Deposit explicitly includes a kill-fee component. Some contracts roll the kill fee into the deposit by structuring it as "50% deposit, of which 25% is non-refundable as a project-commitment fee." In this case, if cancellation happens early, the developer retains the 25% non-refundable component plus invoices the completed work and any remaining kill fee. If cancellation happens late, the 25% non-refundable component is already exceeded by the work performed and the kill fee on remainder is the primary recovery.

Read the engagement letter before sending the cancellation invoice. The math changes based on which case applies, and an invoice that does not match the actual deposit structure invites dispute.

How to write the kill fee clause

The clause language template, adapted from the ClauseShield phase-tiered structure with developer-specific adjustments:

PROJECT CANCELLATION AND KILL FEE : Client may terminate this Agreement for convenience at any time upon written notice to Developer. Upon such termination, Client shall pay Developer (a) all amounts due for work completed through the date of termination at the agreed rates, and (b) a Project Cancellation Fee calculated as a percentage of the remaining unbilled contract value at the time of termination, according to the following schedule:

  • Phase 1 (Discovery and Planning, defined as the period before any production code is written): fifty percent (50%) of remaining unbilled contract value;
  • Phase 2 (Production and Development, defined as the period during active development before delivery for client review): thirty-five percent (35%) of remaining unbilled contract value;
  • Phase 3 (Revision, QA, and Delivery, defined as the period after delivery for client review through final acceptance): twenty-five percent (25%) of remaining unbilled contract value.

Termination for cause, defined as a material breach by Developer of the obligations under this Agreement (including missed milestone deliverables not cured within fourteen (14) days of written notice), shall not trigger the Project Cancellation Fee.

All source code, design files, and project assets remain the property of Developer until full payment of all amounts due, including any Project Cancellation Fee, is received.

The clause does three things at once. It names termination-for-convenience as the trigger and excludes termination-for-cause. It sets the phase-tiered structure explicitly. It establishes the IP-on-payment principle that converts the clause into collectible leverage.

The web developer contract scope-and-revisions post walks through the broader contract structure where this clause lives, including the scope-lock and revision-cap provisions that prevent the scope-creep failure mode this post does not cover.

What to put on the invoice when a client cancels mid-build

Per BillerBear's cancelled-project invoice guide:

"That invoice should include a clear list of work completed or hours worked, a separate line item labeled 'Project Cancellation Fee (per contract).' Clarity matters. Vague invoices invite disputes."

Source: BillerBear Team, "How to Invoice Cancelled Projects" (February 13, 2026)

The two-part invoice structure that holds up under client pushback:

Top section: completed-work line items. List each completed deliverable or each completed week of work at the agreed rate. Reference the engagement letter line item that corresponds. For a React build, this might be: "Discovery and wireframing (Week 1-2)", "Component library and design system (Week 3-4)", "Authentication module (Week 5-6)" with the per-week or per-deliverable rate.

Middle section: deposit credit. Apply the deposit as a credit against the completed-work total. If the deposit fully covers completed work, the line reads "Deposit applied, balance for completed work: $0."

Bottom section: project cancellation fee. One line item labeled "Project Cancellation Fee (per Project Cancellation and Kill Fee clause, Engagement Letter dated [Date])." The dollar amount is the phase-tiered calculation. No further explanation needed; the clause is the explanation.

The web developer invoice post covers the regular-billing invoice structure that the cancellation invoice extends. The format is identical except for the bottom-section cancellation-fee line.

The seven-step cancellation playbook

When the client says 'we're going internal'

Confirm cancellation in writing immediately; respond to the verbal notice with a written 'understood, please confirm by email' message
Pull the engagement letter and identify the kill-fee clause and the current project phase (Phase 1, 2, or 3)
Calculate the completed-work amount through the cancellation date and the kill fee on remaining unbilled value
Verify deposit structure: upfront retainer, non-refundable engagement fee, or split-component
Stop pushing code to the client's repo and stop deploying to the client's production environment until invoices clear
Send the two-part cancellation invoice (completed work plus deposit credit plus kill fee line item)
Set a payment deadline (NET 7 is reasonable for a cancellation invoice given the relationship has ended) and confirm what happens at deadline (IP transfer pauses; collection escalates per contract)

Once both invoices clear, the developer transfers the code to the client's repo and the Webflow project to the client's workspace, and the engagement closes. Once payment is overdue past the deadline, the developer's collection options are the same as any other client-pays-late scenario: written demand, mechanic's-lien-equivalent assertion of IP retention, small-claims if warranted, and a structured collection letter referencing the contract clause.

For the developer who entered the burn scenario without a kill-fee clause in the engagement letter, the playbook is different and harder. The recovery in that case depends on whatever can be negotiated ad-hoc with the departing client, which is usually less than the phase-tiered structure would have produced. The cost of not having the clause is the difference between $4,200 collected as a contractual right and $1,500 negotiated as a courtesy. The lesson for the next engagement is to include the clause.

References

Frequently Asked Questions

Tired of recreating documents from scratch?

Save clients, templates, and brand kit in one place. $49 once. Your data never leaves your browser.

Get 45 Templates + Unlimited Docs for $49