Skip to main content
Ambiguous

is a client's content delay my problem?

It depends — if your contract names a delivery date that assumed timely assets, a client's late content shifts the deadline rather than obligating you to absorb the slip. The exception is a contract that promised a fixed end date regardless of client inputs, which puts the squeeze back on you.

Why this answer

Almost every freelance project has a dependency chain: the client owes you something — copy, photos, logins, approvals, source files — before you can do your part. When that handover is late, the question is who eats the consequence. The honest read is that responsibility tracks cause. If you couldn't start because the client sat on the assets, the slip is theirs and the calendar should move by the length of the delay. But contracts rarely spell this out cleanly, which is why it lands in ambiguous territory. A tight agreement includes a client-responsibilities section and a clause that pauses your clock when an input is overdue. A loose one just names a final date and stays silent on what happens if the client is the bottleneck. In the silent case, you and the client may genuinely read the same situation two different ways, and that gap is where the friction lives. The principle that resolves it: you are accountable for your own turnaround, not for time you were never given to work.

When the answer flips

This leans clearly toward not-your-problem when your contract has a dependency or client-responsibilities clause and you can point to the date an asset was promised versus the date it arrived. It tips back toward your problem if you accepted a fixed end date with no input-contingency language, because then you arguably took on the timeline risk yourself. It also tips if you never flagged the missing asset — silence reads as acceptance, and a client can fairly argue you should have raised the alarm when their part went late. A middle case: the assets arrived in dribs and drabs rather than one clean handover, so neither side can pin a single slip date. There, the fair move is to log each gap as it happens rather than reconstruct it after the fact. And if the delay was small enough that you absorbed it without real cost, chasing a deadline shift is rarely worth the goodwill it spends.

What to do next

Stop the clock in writing the moment an input goes overdue — a short, neutral note beats a buried Slack message. Say plainly: 'I'm ready to start the homepage build but I'm waiting on the final copy; my delivery date moves day-for-day from when that lands.' This isn't a threat, it's bookkeeping, and clients respect it when it's framed as logistics rather than blame. Quote the new date explicitly so there's no drift later. If the client pushes to keep the original deadline despite their own delay, that's a rush-work conversation: you can compress to recover, but compression carries a fee because it costs you evenings, weekends, or other client commitments. Offer the choice clearly — moved date at the original rate, or original date at a rush rate. Going forward, add a clause that pauses your timeline when a named client input is more than a set number of business days late, and you'll never have to relitigate this from memory.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

The client says the deadline was always firm — does their delay change that?+

A deadline is only firm if the inputs it depended on were delivered on time. A fixed end date is an implied promise that both sides hit their handoffs; when the client misses theirs, they've changed the conditions the date assumed. Point to when each asset was due versus when it arrived, and frame the new date as arithmetic: the calendar moves by the length of the gap they introduced. If you'd genuinely promised the date no matter what, that's a harder spot, and the lesson is to never accept a fixed end date without an input-contingency clause attached.

How quickly do I need to flag a missing asset to protect myself?+

Same day, or the next business morning at the latest. The protection comes from the timestamp, not the tone — a calm note saying 'I'm blocked on X as of today' creates the record that the delay started on the client's side. If you wait two weeks and then claim the slip was theirs, you've weakened your own case, because your silence implied you had what you needed. Make flagging a reflex: the moment a promised input doesn't show, you send a one-line status note. It feels almost too small to bother with, and it's exactly what saves the timeline argument later.

Can I bill for time I spent idle waiting on the client?+

Usually not as idle time, and you wouldn't want to — billing for hours you didn't work invites a fight you'll lose. What you can legitimately recover is the downstream cost: if their delay forced you into a rush to hit the back half of the schedule, the rush carries a premium. You can also recover if the delay pushed the work into a period where your rates changed, or knocked it against another booked engagement. The cleaner framing is never 'pay me for waiting' but 'the delay changed the cost of delivery,' and you price that change.

What if the delay is genuinely a little bit my fault too?+

Then split it honestly. If you were slow to ask for the asset, or your spec was unclear so the client didn't know what to send, own your share and adjust the timeline shift to reflect only the portion that was theirs. Shared-fault delays are common and they don't have to be adversarial — the goal is an accurate calendar, not a win. Naming your own contribution first actually strengthens your position on the rest, because it tells the client you're keeping honest books rather than reaching for an excuse. A clear, fair accounting almost always lands better than a tidy story that conveniently blames only them.

The client keeps sending assets in pieces — how do I handle that?+

Define what 'complete' means and don't start the clock until you have it. Piecemeal handoffs are a scope trap because each fragment feels like progress while you can't actually begin real work, and at the end nobody can say when the delay started. Tell the client up front which inputs you need as a single batch before a phase begins, and treat partial deliveries as 'not yet started.' If they prefer to send things as they're ready, fine — but the timeline pauses until the last required piece arrives, and you say so each time a piece comes in. Clarity about the batch is what keeps a trickle from quietly becoming your problem.

Should I build a buffer into my timeline to absorb client delays?+

A small one, yes — a few days of slack on either side of a delivery date is just professional realism, and it spares you from renegotiating over minor slips. But a buffer is not a substitute for a dependency clause, and you should never size it to silently swallow weeks of client lateness, because then you're financing their disorganization out of your own schedule. Use the buffer for the small, normal friction of real projects, and use the contract clause for anything larger. The two work together: the buffer keeps the relationship smooth, and the clause keeps a serious delay from becoming an unpaid emergency on your end.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide