When a Client Isn't Using the Build You Delivered (And How to Fix It)
- A client who paid for a build and then does not use it is a quiet risk. They will not complain, but they will not renew, refer you, or hire you again, because in their mind the project did not work.
- Use the Profit Room's Adoption Check: look at whether it is being used before you assume, ask one plain question, find the specific blocker, fix real problems for free, offer training or changes as paid work, and agree on one small first use the team can do this week.
- Prevent it next time. Name an owner on the client side before you build, design the handoff around their daily routine, train the people who will use it, and schedule a check-in after launch so you catch low use early.
The Short Answer
When a client isn't using the build you delivered, reach out early and ask what got in the way, without blame. Then find the one specific blocker: a missing login, a step that does not fit how the team works, nobody assigned to it, or a real bug. Fix genuine defects for free. Offer extra training, workflow changes, or new features as paid work. Then agree on one small, concrete use the client will try this week, and check back.
That is the Adoption Check method. It matters because an unused build is the most expensive outcome for you, even after the invoice is paid. A client who does not use what you built will not see the value, will not renew a maintenance plan, and will not refer anyone. Getting the build used is part of [delivering a build so clients come back](/blog/deliver-a-build-so-clients-come-back).
Why Clients Stop Using a Build
The reason decides the fix, so find it before you change anything.
- Nobody owns it. The person who hired you is busy, and nobody on the team was told the build is now part of their job.
- It does not fit the routine. The build works, but it lives in a separate place the team has to remember to open, or it adds a step to a process they already rush through.
- One early blocker. A login did not work, a field was confusing, or the first result looked wrong, and the team quietly went back to the old way.
- The team was never shown. The owner saw the demo, but the people who would use it every day did not.
- Priorities changed. The business moved on to something more urgent, and the build lost its place in line.
- It is actually a bug. Sometimes low use means the build is not doing what was agreed. That is on you, and it is free.
Most of these are not about code quality. They are about the handoff, and that is good news, because handoff problems are usually small and fast to fix.
Run the Adoption Check
Use these steps when a build you delivered seems to be sitting idle.
- Look before you assume. If you still have permission to see usage, check logins, records created, or messages sent. If you do not, ask. Do not guess, and do not log into a client system you are no longer authorized to use.
- Ask one plain question. Something like: 'I wanted to check in on the booking assistant. How is it fitting into the week so far?' Open questions get honest answers. Accusing questions get silence.
- Find the specific blocker. Ask who is supposed to use it, when they would use it, and what happened the last time they tried. Keep going until you have one concrete reason, not a vague 'we have been busy'.
- Sort defect from change. If the build does not do what the scope said, fix it for free and quickly. If it works as agreed and the client needs it to work differently, that is a change with a price and a date. A [change order template](/blog/change-order-template-for-a-claude-code-project) keeps it clean.
- Agree on one small first use. Pick one task the team will do with the build this week, such as handling one type of request or running one report. Small wins rebuild the habit faster than a big relaunch.
What to Fix Free and What to Charge For
Be generous on anything that was your responsibility, and fair on anything new.
| Blocker | Who owns it | What to do |
|---|---|---|
| It does not work the way the scope described | You | Fix it free, and say so |
| Logins or access set up wrong at handoff | You | Fix it free and confirm it works for each user |
| Daily users were never trained and training was in scope | You | Run the training you owed |
| Team needs training that was not in scope | Client | Offer a short paid walkthrough |
| Build needs to work differently to fit a new process | Client | Send a change order |
| Nobody on the client side owns it | Client | Ask them to name one owner before anything else |
Sorting an adoption problem
Claude Code can help with the diagnosis on your side. With the client's permission, it can read through logs or error reports you have access to and help you trace why a flow fails for a certain user. You still decide what is a defect, what is a change, and what to tell the client.
Set Up Handoffs That Get Used
The best fix is a handoff designed for adoption from the start.
- Name an owner before you build. Ask who on their team will use it every day and who will be responsible for it. [Setting client expectations before a build](/blog/set-client-expectations-before-a-claude-code-build) covers the conversation.
- Build into their routine. Put the build where the team already works, such as their inbox, their chat tool, or the system they open every morning, instead of one more tab to remember.
- Train the people who will use it. Walk the daily users through it, not just the person who signed. A short recorded walkthrough they can come back to helps.
- Agree on what success looks like. Pick one or two signs that it is working, such as requests handled or hours saved, and show them in a simple report. [A client reporting dashboard](/blog/build-a-client-reporting-dashboard-with-claude-code) makes that visible.
- Schedule the check-in. Put a short call on the calendar a couple of weeks after launch to catch low use before it becomes the norm. A [weekly client update](/blog/weekly-client-update-prevents-fires) during the first month keeps it on their radar.
- Offer ongoing support. A [maintenance plan](/blog/package-a-maintenance-plan-for-ai-builds) gives the client a reason to keep using and improving the build, and gives you a reason to keep watching it.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do if a client isn't using the build I delivered?
Reach out early and ask, without blame, how it is fitting into their week. Find the one specific blocker, fix any real defect for free, offer training or changes as paid work if they were not in scope, and agree on one small use the team will try this week.
Is it my problem if a client doesn't use what I built?
Partly. If the build does not work as agreed, or setup or training you owed was missed, that is yours to fix. If it works and the client never assigned anyone to use it, that is theirs, but it still affects your renewals and referrals, so it is worth helping.
Should I offer free changes to get a client using the build?
Fix defects and anything that was in scope for free. Changes that make the build work differently than agreed are new work with a price and a date. Rebuilding for free rarely fixes adoption, because the real blocker is usually ownership or routine.
How do I check whether a client is using the build?
If you still have permission, look at usage signs such as logins, records created, or messages handled. If you do not have access, ask the client. Never log into a client system you are no longer authorized to use.
How do I make sure clients use the builds I deliver?
Name an owner on their team before you build, put the build inside the tools they already use, train the daily users, agree on what success looks like, and schedule a check-in a couple of weeks after launch.
Last reviewed October 20, 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 →