When a Client Wants Free Help After the Project Ends (Turn Favors Into Paid Work)
- A client who keeps asking for free help after handover is usually not trying to take advantage of you. They liked working with you, they do not know where the project ended, and nobody told them what happens next. Every free yes teaches them the help is included.
- Use the Profit Room's Handover Line method: sort every request into a defect, a how-to question, or a new change. Fix real defects in what you delivered. Answer quick how-to questions once, with a pointer to the handover docs. Quote everything else as paid work or point them to a support plan, in writing, without apology.
- Prevent it next time. Write what support is included and for how long into your agreement, close every project with a clear handover message, and offer a monthly plan before the client needs it.
The Short Answer
When a client keeps asking for free help after the project ends, stop handling each message as a one-off favor. Sort the request first. If something you delivered is broken, fix it, because that is part of doing the job right. If it is a quick question about how to use what you built, answer it once and point to the handover docs. If it is a new change, a new feature, or work on something you never built, reply with what it takes and a price, or point them to a support plan.
That is the Handover Line method. It works because the problem is rarely the client. It is a missing line between 'the project' and 'after the project.' When you draw that line clearly and kindly, most clients happily pay, and the few who only wanted free help sort themselves out.
Why Clients Keep Asking
The reason shapes how you word the reply, so figure out which one it is.
- Nobody said the project ended. If the last message was 'it's live!' and nothing more, the client has no reason to think your help stopped.
- You said yes before. One free fix teaches them that small changes are included. Five free fixes make it an expectation.
- They do not know what counts as small. To a client, changing a button and adding a new integration can look like the same size of request.
- Something really is broken. Sometimes the 'quick favor' is a real defect in your work. [When a client finds a bug after launch](/blog/client-finds-a-bug-after-launch) covers that case in detail.
- They trust you more than anyone else. You are the person who understands their system now, so you are the first call for anything nearby, even things you never built.
In nearly every case, the client is a happy client. That is good news. A happy client asking for more help is a client who would pay for more help if you offered it clearly.
Run the Handover Line
Reply to the next request within a working day, and follow these steps in order.
- Sort the request. Is it a defect in what you delivered, a question about how to use it, or a new change? Check it against your scope of work, not your memory. Claude Code can help you compare the request against the original scope and the handover notes, but make the call yourself.
- Fix real defects without a fuss. If something you built does not do what the scope said it would, fix it. That protects your reputation, and it is the right thing to do.
- Answer how-to questions once. Give a short answer and point to where it lives in the handover docs. If the docs do not cover it, add it, so the next question answers itself.
- Quote new changes in writing. Say what the change involves, how long it will take, and what it costs. Keep it short and friendly. A [change order](/blog/change-order-template-for-a-claude-code-project) works the same after launch as it does mid-project.
- Offer the ongoing option. If requests keep coming, the client does not need a string of small invoices. They need a monthly support plan, and now they have a real reason to want one.
What to Fix Free and What to Charge For
Be generous where it costs you little and builds trust, and firm where the work is real.
| Request | Free or paid | Why |
|---|---|---|
| Something you built does not work as the scope described | Free | It is part of delivering what you sold |
| A quick question about using what you built | Free, once | Answer it and add it to the handover docs |
| Changing text, layout, or settings they could ask for anytime | Paid, or a support plan | It is new work, however small |
| A new feature or integration | Paid, scoped as its own project | It is a new build with its own risk |
| Broken because their tools, accounts, or data changed | Paid | The cause is outside what you delivered |
| Help with systems you never built | Paid, or turn it down | You are taking on risk you never scoped |
Sorting after-launch requests
If a client pushes back on paying for a change, do not argue about whether it is small. Point back to the scope you both agreed to, and keep the offer open. If a pattern of free requests is wearing on the relationship, [how to fire a client without burning the relationship](/blog/how-to-fire-a-client-without-burning-the-relationship) covers when to step away.
Set It Up So It Does Not Happen Again
The easiest fix is making the line visible before the project ends. Add these to every project.
- Write the support window into your agreement. Say how long you fix defects after launch and what counts as a defect. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where that line fits.
- Send a clear handover message. Say the project is complete, list what was delivered, link the docs, and say how to request changes from here.
- Offer a support plan at handover. Clients say yes more easily while the build is fresh and they can see how much they rely on it. [Packaging a maintenance plan for AI builds](/blog/package-a-maintenance-plan-for-ai-builds) covers how to structure it.
- Track every small favor. Even if you choose to do one for free, log it. When the list grows, you have a clear, friendly reason to suggest a plan.
- Check in on purpose. A [quarterly review call](/blog/quarterly-review-call-with-clients) turns 'can you just' messages into planned, paid work.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do when a client wants free help after the project ends?
Sort the request first. Fix real defects in what you delivered, answer quick how-to questions once with a pointer to the docs, and quote any new change in writing as paid work or offer a monthly support plan.
Should I fix bugs for free after a project ends?
Fix defects in what you delivered, meaning anything that does not work the way the scope described, for the support window in your agreement. Problems caused by changes to the client's own tools, accounts, or data are new work.
How do I tell a client that more help will cost money without upsetting them?
Keep it warm and specific. Say you are happy to help, that the finished project covered the original scope, and then give the time, price, and start date. Offering a support plan as a second option makes it feel like a choice, not a refusal.
Is it okay to do small favors for a good client?
Yes, if you choose to, but log each one and say it is a one-time favor. Unlogged favors quietly become an expectation, and a growing list is the best reason to suggest a support plan.
How do I stop this from happening on the next project?
Write the support window into your agreement, send a clear handover message saying the project is complete, and offer a monthly support plan at handover, before the client starts sending requests.
Last reviewed October 17, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →