ZAMBO.

Direct answer

The project is finished. The free help is not endless. Here is the line.

The project shipped, the client accepted it, the invoice went out, and the small requests never stopped: a tweak here, a question there, something that looks broken, something new they would like added, all arriving with the same assumption, that support after delivery is simply part of what they bought, forever, for free. Some of it is yours to cover. Most of it is not, and the difference is not attitude, it is a sort you can run against the delivery record in about a minute per request. Here is the sort, the window that makes it fair, and the exact close that stops the drip without burning the client.

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

Updated October 28, 2026. First published October 28, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service.

Step 1. Sort every request into three piles against the delivery record

Every post-project request is one of three things, and each pile has a different price. Pile one, a defect: the delivered work does not do what the brief and the delivery record say it should. Defects are yours, repaired free, and owning them fast is what makes the other two piles defensible. Pile two, a question: how does this work, where is that setting, can you show us again. Questions cost minutes, not hours, and a short answer or a pointer to the handover notes covers most of them; a pile of questions is a training need, which is pile three in disguise. Pile three, new work: changes, additions, improvements, and anything the brief never promised. New work is a new stage, priced and accepted before it starts, no matter how small each piece feels. The sort runs against the record: what was briefed, what was delivered, what was accepted. If a request matches a promise in that record and the work fails it, it is a defect. If it is not in the record, it is not support.

Step 2. Put a stated fix window on every delivery, starting now

The window is what turns the sort from your opinion into a term both sides saw: defects reported within a stated period after acceptance, commonly 14 to 30 days for most freelance work, are repaired free. Inside the window, the client reports, you check against the record, and a real defect gets fixed without a negotiation each time. After the window, even a defect conversation changes shape: you will still usually fix a clear miss, but as a quoted repair or under a support arrangement, decided case by case, not as an unlimited promise made by silence. If your finished project never had a window stated, state one now, in the closing message in step 5, applied fairly: defects in what you delivered, reported promptly, are covered; the window starts from that message for the work already delivered. Clients accept a window stated plainly far more easily than a refusal invented per request.

Step 3. Read the two states a delivery can sit in when a request arrives

The sort only works if the delivery itself is a record the client already decided on. 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 states a finished project can sit in:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, decided 2026-10-16T14:31:51.146Z in that example, is a closed delivery: the support window runs from that acceptance, and every later request is sorted against exactly what was accepted. A pending record, 5 of 5 steps checked and release_hint hold, is delivered work nobody formally accepted yet, and there the honest first move is to get the acceptance, because without it the project is not finished in any sense either side can point at, and support has no start date. Close the acceptance first; the window conversation follows it naturally.

Step 4. Answer each request with its pile, in one short message

Do not debate the philosophy of support. Answer the request in front of you, with its pile named and the next step attached. A defect: you are right, that is not what the delivery record promises, it is fixed under the window, done by Thursday. A question: short answer here, and the handover notes cover the rest of this family. New work: happy to do it, that is outside the delivered scope, so here it is as a small stage with a price, say the word and it starts today. Naming the pile does two things at once: the client learns the system from experiencing it, fairly, on real requests, and your free work shrinks to exactly the pile you owe. The requests do not stop arriving. They start arriving pre-sorted, because clients adapt quickly to a line that is consistent and quick.

Step 5. Close the finished project in writing, even if it ended weeks ago

If the project closed without a closing message, send one now. It is not a complaint and it is not a new contract; it is the summary the record already supports: the work delivered and accepted on its date, the defect window and its end date, what happens after the window (repairs and changes quoted as small stages, or a monthly support block if they want one), and where the handover record lives. The copy-paste shape: A quick close-out note so we both have it in one place. The project was delivered and accepted on the date at the record link. Defects in that delivered work, anything that does not match what the record shows was promised, are on me free until the window date shown; just point at the item. After that date, fixes and changes still get done, quoted first as small stages so you always approve the cost before the work. If you would rather have cover without thinking about it, a small monthly support block is available and I can size it from the requests so far. Send it warmly. You are organizing, not warning.

Step 6. Offer the paid shape for clients who genuinely need ongoing cover

Some clients are not gaming anything; their work genuinely needs someone on call, and the free drip is just what an unstructured need looks like. For them, convert the pattern into the product: a monthly support block, a stated number of hours at your rate, requests logged against it on the same record, balance visible, defects in the original delivery still sorted separately and honestly. The record from the last months of requests is your sizing evidence, which makes the pitch factual instead of salesy. Clients who decline the block have also made a decision, and it is a fair one: requests go back to the sort, quoted per stage. Either way, support stops being an assumption and becomes a choice the client made in writing.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the work was free of defects, does not decide whether a request is a defect or new work, and cannot make a client accept a support window. The brief, the delivery record with its acceptance, and the closing message you both saw are what the conversation stands on. This page is general information, not legal advice.

Frequently asked questions

My client expects free support after the project is finished. How long should I support it for free?

Support the defects for free, inside a stated window, and nothing else by default. A fair standard shape: defects in the delivered work, meaning anything that fails what the brief and the delivery record promised, reported within about 14 to 30 days of acceptance, are repaired free. Questions get a short answer or a pointer to the handover notes. Everything else, changes, additions, training, and new requests of any size, is new work: a small stage, priced and accepted before it starts. If no window was ever stated on the finished project, state one now in a warm closing message that recaps the delivery, its acceptance date, and the window end date. Forever is not a window, and a window stated plainly is not unfriendly; it is the term that lets you fix real defects fast without funding every later idea.

How do I tell whether a request is a defect or new work?

Run it against the record, in order. What did the brief promise, in words? What does the delivery record show was delivered? Did the client accept that delivery? If the delivered work fails a promise in the brief, it is a defect, yours, free inside the window. If the request asks for something the brief never promised, a different result, a new audience, an extra format, a behavior that was never specified, it is new work however small it feels. The gray middle, where the brief was vague, is decided honestly case by case, and the lesson priced into the next brief: specificity at kickoff is what makes the sort cheap at close.

The client says support was implied and I am being difficult. What do I send?

Send the record and the close, not a defense of your character: the delivery and its acceptance date, the defect window with its end date restated, and your answer to their actual current request sorted into its pile with the next step attached, a fix date for a defect or a priced stage for new work. Difficulty is hard to argue with when the same message fixes what is owed and prices what is not, quickly and in writing. Most implied-support claims are really unclosed projects talking: once the close exists in one message both sides can point at, the claim loses the fog it lived in.

Should I just do the small free requests to keep the client happy?

A small request answered free once, as goodwill, labeled as goodwill in the reply, can be good business. The same requests answered free silently, every week, are a support contract you never priced and cannot stop without a fight, because each free answer sets the precedent the next request cites. The test is pattern, not size: the second time the same family of request arrives, it gets its pile and its price or its place in a support block. Happy clients are kept by fast, fair sorting, not by an endless free tier they did not know they had until you tried to end it.

How do I close a project so the support boundary exists from day one?

Close every delivery as a handover the client accepts, with the support terms riding on the same record: the item list and results, the explicit accept action, the defect window and its dates, and the rule that changes after acceptance are quoted stages. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and the acceptance state, accepted with its decider and date, or pending, is already on the record when the first support request arrives. New users get 20 free calls per day, then they upgrade when the job needs more. For $0.99, close the next delivery that way and let the record answer the support question before it is asked: get the 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