Direct answer
A pause protects nobody by default. The paperwork is the protection.
Pauses kill projects at the restart, in arguments about what was finished and what it was worth, held by people working from three-month-old memories. Here is how to park a project properly: pause note, frozen record, acceptance and invoice now, restart terms in writing.
Updated October 20, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.
A pause is a state change. Treat it like one.
Projects rarely die during a pause. They die at the restart, in the argument about what was finished, what was agreed, and what the finished part was worth, conducted by two people whose memories of the job are three months old and were never identical in the first place. The protection is not legal armor. It is doing, in the last week before the pause, the four closing jobs that most freelancers postpone until restart day: writing the pause down, freezing the work into a record, getting it accepted, and invoicing it. Postponed, those jobs are hard. Done now, while the client is present and the work is fresh, they are an afternoon.
Step 1. Get the pause in writing
A pause agreed in a call does not exist. The pause note, set out line by line in the FAQ below, converts a friendly conversation into the document the restart will actually run on. Two lines matter most and are the two most often skipped. The restart window: a window, honestly stated, because a client who says a few months and means a year has set you both up to fail. And the hold date: the day until which your prices and availability stand, after which the restart is a re-quote. Writing that date is not unfriendly. It is what lets you be friendly during the pause itself, because neither side is quietly assuming something the other never promised.
Step 2. Freeze the work into a record on pause day
On the pause date, stop mid-step work where it stands and save the state of everything: completed stages, the open stage with exactly how far it got, and the decisions already made. Deliver the completed work as one record the client can open during the whole pause. If the job ran through Zambo, the record already exists and reads like the two public examples below:
Accepted: this stage is a settled fact, not a claim
- Status: accepted by the client on 2026-10-16, decision ok_to_release.
- The record covers 4 steps, 4 of 4 checked, each with the time it was saved.
- The acceptance sits on the record itself, in its acceptance.json, linked below.
- Open the handover or read its acceptance.json.
Still open: delivered, checked, and waiting on the client
- Status: still pending, decision hold. The client has not accepted or flagged it yet.
- The record covers 5 steps, 5 of 5 checked, saved on 2026-10-16.
- Pending is a documented state, not a gap in your paperwork: the work is on the record and the unfinished decision is the client's.
- Open the handover or read its acceptance.json.
The accepted record is what you want every completed stage in before the pause: decided by the client, dated, closed. The pending record is the dangerous one to carry into a pause, because a decision postponed before the pause is a decision that has to be made cold, months later, by someone who may have changed roles. Whatever is still pending on pause day gets a decision request attached to the pause note itself: accept or flag these stages before the pause starts, so the project parks with no unfinished decisions inside it.
Step 3. Invoice the completed work now
Pause day is invoice day for everything completed and accepted. The reasoning is set out in the FAQ, and the short version is that money follows memory: both are freshest now. Describe open stages in the pause note instead of invoicing them, so the invoice that does go out is clean and payable without argument. If the agreement holds a deposit against later stages, the pause note states what happens to it during the pause, in the agreement's own terms. Never let a deposit's status be a thing the restart has to negotiate.
Step 4. Write the restart before you need it
The restart is a small project with its own shape: a re-brief where the client confirms the goal still stands, a check of the record together, stage by stage, so both sides restart from the same facts, and a schedule written after that check, not before it. Put that shape in the pause note and the restart has a path. Leave it out and the restart begins with the client asking you to simply carry on, from a state neither of you can prove, at prices one of you remembers differently.
If the pause turns into silence
A pause with a written window has a built-in test: when the window closes and no restart message has come, write once, briefly, restating the record link, the state of the work, and the hold date passing. After that, treat the project as closed: the completed work is invoiced and on the record, the open stages are documented as open, and your calendar is free. That is the whole payoff of the paperwork. A protected pause can end quietly without costing you anything, because nothing of yours is trapped inside it.
What this page does not settle
Whether you must hold prices, availability, or a deposit during a pause depends on your written agreement, and agreements differ. This page is general information, not legal advice. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the work was good, and an acceptance state shows the client's recorded decision, not their intention to restart. Zambo never holds your money or the client's.
Frequently asked questions
My client wants to pause the project for a few months. How do I protect the work already done?
Protect it before the pause starts, in four moves, all of them done while the client is still talking to you. One: get the pause in writing, with the pause date, the expected restart window, and who owns the decision to restart. Two: freeze the work as it stands and deliver everything completed so far as one record, so the state of the job on pause day is a fact neither side has to reconstruct months later. Three: get the completed work accepted now, while the client still remembers it, and invoice for it now, on the record they accepted. Four: write the restart terms into the same note: your schedule and prices are held only until a stated date, and restarting begins with a short re-brief, not with the assumption that nothing changed. A pause handled this way is a parked project. A pause handled with a handshake is a cancellation that has not admitted it yet.
Should I invoice for the finished work before the pause starts?
Yes. The pause is exactly when completed stages should be invoiced, for three reasons. The client's memory of the work is freshest now, so acceptance is easiest to get now. The client's budget for this project exists now; a budget that survives a pause is a hope, not a plan. And an invoice sent at pause day is a normal closing document for the phase, while an invoice sent three months into silence reads as a surprise. Invoice the completed stages in full, credit any deposit the way the agreement says, and leave genuinely unfinished stages uninvoiced, described in the pause note as not started or part done, so the restart conversation begins from a clean line.
What should the written pause note include?
Six lines cover it. The project and the phase being paused. The pause date and the expected restart window, stated as a window and not a promise. The state of the work: which stages are complete, accepted, and invoiced, and which are open, with the record link that shows it. What happens to deposits and part payments under the agreement. The date until which your prices and availability are held, and what happens after it: a re-quote and a new schedule. And the restart trigger: who writes to whom, and that restarting opens with a re-brief. Both sides confirm the note in writing. It takes ten minutes and it is the whole difference between a pause and a drift.
How long should I hold the work, the files, and my place in the schedule?
Hold the record for as long as you keep client records at all: it costs nothing to keep and it is the project's memory. Hold working files and project state until the restart window in the pause note closes, plus a sensible margin, and say that date in the note so nobody is surprised. Hold your schedule for nobody beyond the date you wrote down. A pause reserves the work, not your calendar. If the client restarts inside the window, the re-brief is short and the record carries the context. If they restart after it, the project is honestly a new engagement that starts from an unusually good record of the old one.
How do I set up the next project so a pause cannot strand the work?
Build the job in stages that close as they go: delivered, accepted, and invoiced stage by stage, so at any moment the most a pause can strand is the one open stage. When the work runs through Zambo, each stage sits on a handover record with its own acceptance state, accepted and ok_to_release, or still pending and hold, so pause day needs no archaeology: the record already says what is done, what is decided, and what is open. For $0.99, run the next project on that footing for a day and see what pause-proof looks like from the inside: https://zambo.dev/day-pass/ A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.
Related
- My client went quiet in the middle of a project. How do I restart it or close it out?
- How do I invoice for work a client cancelled halfway through?
- Can I stop work if a client has not paid my last invoice?
- My client paid part of the invoice and stopped responding. What do I do?
- My client wants me to transfer the copyright before they pay in full. Should I agree?
- Start with your problem: every problem in this directory, routed to its page