ZAMBO.

Direct answer

One big invoice is one big risk. Stages make it small ones.

Getting burned on a big project rarely happens all at once. It happens at the end, when months of work sit inside one unpaid invoice. Milestones fix the shape: the job is cut into stages, each stage ends in work the client can check, and each stage is accepted and paid before the next one starts. Here is how to cut, price, and run the stages so the most you can ever lose is one stage.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 24, 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.

Step 1. Cut the job into stages that end in something checkable

A stage is not a percentage of effort; it is a finished piece the client can open and judge: the research summary, the first draft, the working version, the final files. Three to five stages fit most big projects. Fewer makes each payment too big to be a checkpoint; more makes the admin heavier than the protection. Write each stage as three lines: what is delivered, how the client checks it, and what counts as accepted. If a stage cannot be checked, it cannot be a milestone; redraw the line until every stage ends at something visible.

Step 2. Attach an amount to every stage, and keep the last one small

Open with a deposit stage, commonly a quarter to a third of the price, paid before work starts; it books the job and covers your setup. Price the middle stages by the weight of the work in them, not by the calendar. Keep the final balance the smallest slice, a tenth to a fifth, because the end of a job is where attention wanders and leverage matters most: you want the client finishing a small payment, not deciding a large one. Write the full schedule, amounts and stage names, into the agreement before anyone starts, so no stage price is ever negotiated mid-job with work held hostage on either side.

Step 3. Run every stage on a record: delivered, checked, accepted

The money only protects you if the stage state is a fact, not a memory. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the two states a stage can sit in:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted stage, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, is a stage that is finished in every sense: delivered, checked, decided. The next stage starts from solid ground. A pending stage, 5 of 5 steps checked and release_hint hold, is work delivered and inspected with the decision still open, which is exactly the state a milestone schedule exists to name. Point at the state when you invoice the stage. When the work runs through Zambo, each stage is delivered as a handover the client checks and accepts step by step, so the stage line is visible to both sides at the same time.

Step 4. The start rule: the next stage starts on acceptance plus payment

This one rule does most of the work. A stage is invoiced on delivery, the client checks and accepts it, the payment lands, and only then does the next stage begin. Not on a promise, not on the payment being in the post, not because the schedule is tight. State the rule in the agreement and in the stage one delivery message, warmly and once, so enforcing it later is just following the plan. Clients who respect milestones are not slowed by the rule at all; their acceptance and payment take a day. The rule only ever binds the client who would otherwise have stacked three stages of work onto one overdue invoice.

Step 5. Price changes at stage boundaries, never mid-stage

Big projects attract changes. Milestones give changes a clean place to land: the boundary between stages. A change asked mid-stage gets named, noted, and quoted to start at the next boundary, as its own small stage or an addition to the next one, accepted in writing before it is worked. Inside a stage, the price and the contents stay exactly as agreed, which protects the client from surprise extras as much as it protects you. The boundary conversation takes five minutes while the schedule is calm. The same conversation mid-crisis, with a deadline burning, is where discounts and resentments are born.

Step 6. When a stage stalls, pause the schedule, not the relationship

A stage can stall two ways: delivered and unpaid, or paid and waiting on the client's input. Both get the same calm shape: name the stage state on the record, state the date the schedule resumes from when the block clears, and hold later stage dates as estimates until then. Do not quietly absorb a three week client delay into your delivery date, and do not start the next stage early out of goodwill while the current one is unpaid; both habits convert the client's stall into your loss. The schedule restarts when the block clears, and the record shows whose court the ball was in, without anyone having to argue about it.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove a stage was worth its price, does not make a client accept work they judge wrong, and cannot collect a stage payment by itself. The stage definitions, the amounts, and the start rule in the written agreement are what the record supports. This page is general information, not legal or financial advice.

Frequently asked questions

How do I split a big project into milestone payments so I do not get burned?

Cut the job into three to five stages, each ending in a deliverable the client can open and check, and write each stage as what is delivered, how it is checked, and what counts as accepted. Attach an amount to every stage in the agreement before work starts: a deposit stage of about a quarter to a third, middle stages priced by the weight of the work, and the smallest slice, a tenth to a fifth, as the final balance. Deliver each stage on a record, invoice it on delivery, and run the start rule: the next stage begins only when the current one is accepted and paid. Price changes at stage boundaries, never mid-stage. Run that way, the most you can ever lose is the stage you are standing in, instead of the whole job at the end.

How many milestones should a project have?

Three to five for most projects: a deposit, one to three work stages, and a final balance. The test is not the count but the checkpoint size: each stage payment should be small enough that its loss would sting without sinking you, and each stage should end at something the client can actually check. Very small jobs need only two slices, half before starting and half before final delivery. Very long jobs can split the middle into more stages, one per finished piece, rather than one per month, because a calendar milestone pays for time passing while a deliverable milestone pays for work the client can see.

What percentages should each milestone be?

A common working shape is a quarter to a third as the deposit before work starts, the middle stages sharing about half the price in proportion to the work inside them, and a tenth to a fifth held as the final balance on delivery. Two principles matter more than the exact numbers. First, money collected should always stay slightly ahead of work delivered, so you are never financing the client's project. Second, the final slice stays the smallest, because a client deciding a small last payment behaves differently from one deciding a large one. Write the amounts as fixed sums per stage, not only percentages, so every invoice is a number both sides already agreed.

What if the client wants to pay everything at the end?

Treat it as the risk decision it is: one end payment means you carry the whole cost of the job until the day the client decides. You have three honest doors. Keep milestones and explain they protect the client too, since they only ever pay for checked work. Shrink the exposure: a larger deposit and one middle stage is still a schedule. Or price the end payment shape openly, with final files and usage rights transferring only after the payment lands, and a written acceptance of the delivered work before that. What you should not do is accept end payment silently and hope; hope is the arrangement that produced every burned at the end story in the first place.

How do I keep every stage checkable instead of arguing from memory?

Deliver each stage as a record the client opens: the steps that ran, the saved results, and a place to accept or flag a step, so the stage state is visible to both sides at once. When the work runs through Zambo, every stage is a handover with a verifiable receipt for each step under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and the acceptance is recorded with its date and decider. For $0.99, deliver one stage that way and watch how the next stage conversation changes when the state is a link instead of a recollection: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 for 30 days (one payment) or $290 for 365 days, and $19 for 30 days for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related