When a Client Asks for a Feature You Think Is a Bad Idea
- A client asking for a feature you think is wrong is normal. It is their business and their money. Your job is not to win the argument. It is to make sure they decide with the full picture, and that nobody is surprised later.
- Use the Profit Room's Flag, Offer, Record method: flag the concern once, in plain words, tied to their goal; offer a better option or a cheap test; then record what they decided in a short email. If they still want it, build it properly and price any change to the scope.
- Refuse only when the feature is unsafe, breaks the law or a platform's rules, puts other people's data at risk, or is something you are not willing to put your name on. A feature you simply would not have chosen is not a reason to say no.
The Short Answer
When a client asks for a feature you think is a bad idea, tell them once, clearly, and explain why in terms of their own goal. Offer a better option if you have one. Then let them decide, and write down what they decided. If they still want it, build it as well as you would build anything else. Do not quietly build a weaker version, and do not keep raising the same objection in every call.
That is the Flag, Offer, Record method. It works because it separates two jobs that builders often blur together: giving advice, which is your job, and making the call, which is the client's. Clients hire you partly for judgment, so staying silent is a failure too. But once you have said your piece, the decision belongs to the person paying for the build.
Why Your Gut Is Not Enough
Before you push back, check what kind of 'bad idea' this is. Many features that look wrong to a builder are right for the business, because the client knows things you do not: what their customers keep asking for, what a big account demanded, or what their boss will ask about on Monday. Sort the request into one of four buckets first.
- Taste. You would design it differently, but it works. This is not worth a fight. Mention it if you like, then build what they asked for.
- Cost. It will take far longer or cost more to run than the client thinks. This is worth flagging, with a rough sense of the extra work, because it changes the price and the timeline.
- Outcome. You think it will hurt the goal the build exists for, like a signup form so long that fewer people finish it. This is the core case for Flag, Offer, Record.
- Risk. It is unsafe, breaks the law or a platform's rules, or exposes other people's data. This is the one case where you may need to say no, covered at the end.
Most requests land in the first two buckets. Treating a taste difference like a risk is how builders end up with a reputation for being hard to work with, and it makes your real warnings easier to ignore. Save your firm voice for the requests that deserve it.
Run Flag, Offer, Record
Work through these in order, and keep each step short.
- Ask what the feature is for. 'Help me understand what you want this to do for the business.' Half the time the answer reveals a goal you can reach a better way, and the disagreement disappears.
- Flag the concern once, tied to their goal. Not 'this is a bad idea' but 'I think this will make fewer people finish signing up, which is the number you told me matters most.' Be specific about the cost or the risk, and say how confident you are.
- Offer an option. Suggest a better way to reach the same goal, or a cheap test: build a small version, measure it, and decide with real numbers. In the Claude Code desktop app you can often mock up both versions in the same session, so the client compares them instead of comparing opinions.
- Let them decide. Ask directly: 'Do you want to go with the original version or the alternative?' Then accept the answer without sulking.
- Record the decision. Send a short email: what they asked for, the concern you raised, the option you offered, and what they chose. If the choice changes the scope, attach a [change order](/blog/change-order-template-for-a-claude-code-project) before you start.
| Type of request | Example | What to do |
|---|---|---|
| Taste | A color, layout, or wording you would not pick | Mention it at most once, then build it |
| Cost | A feature that triples the build time or running costs | Flag the cost in writing and price it as a scope change |
| Outcome | A step that you expect will lower signups or sales | Flag, offer an alternative or a small test, record the choice |
| Risk | Collecting data nobody needs, or skipping consent | Explain the risk plainly and decline that part if it does not change |
Flag, Offer, Record: matching the response to the request
What to Say
Notice what the message does. It leads with 'I can build this', so the client does not feel blocked. It names one concern, not five. It ties the concern to the client's own goal instead of your taste. It offers a way forward, and it ends by handing the decision back. It also tells them you will write it down, which makes the email feel routine rather than defensive.
Once they decide, stop arguing. If the feature underperforms later, your email means nobody has to rely on memory, and you can say 'let us look at the numbers and adjust' instead of 'I told you so.' That tone keeps you on the account. If the feature becomes the subject of blame anyway, [the client blames your build](/blog/client-blames-your-build-for-a-problem-it-didnt-cause) covers how to handle it, and the written record is your best friend there.
When to Say No
Disagreement alone is never a reason to refuse. A few things are. If the feature would put people at risk, break the law or a platform's terms, collect or expose personal data the client has no good reason to hold, or mislead the client's own customers, explain the problem plainly and decline that part of the work. You can still build everything else. If the client is asking you to copy someone else's work, [when a client wants you to copy a competitor](/blog/client-wants-you-to-copy-a-competitor) covers where that line sits. None of this is legal advice, so if the question is whether something is lawful, tell the client to ask their lawyer before you build it.
The other valid reason is your own name. If a feature would make the build something you would not be willing to show or support, you can decline it, and if it is central to the project you can [turn down the project politely](/blog/how-to-turn-down-a-client-project). To have fewer of these conversations mid-build, talk about how you handle disagreements in your [expectations conversation](/blog/set-client-expectations-before-a-claude-code-build) and spell out what is in and out in a [clear scope of work](/blog/scope-of-work-that-prevents-scope-creep).
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Should I build a feature I think is a bad idea?
Usually yes, after you have flagged your concern once and offered an alternative. It is the client's business and their decision. The exceptions are features that are unsafe, unlawful, or expose people's data.
How do I tell a client their idea is bad without upsetting them?
Do not call it bad. Tie your concern to the goal they told you matters, say it once, offer another option or a small test, and hand the decision back to them.
Should I write down that I disagreed?
Yes. A short email recording what they asked for, your concern, the option you offered, and what they chose keeps everyone clear and protects you if the feature is questioned later.
Can I charge extra for a feature I advised against?
If it is outside the agreed scope, yes. Price it as a change to the scope, the same as any other addition, and get approval before you start.
What if the feature hurts results after launch?
Look at the numbers together and suggest an adjustment. Skip 'I told you so.' The decision email already shows what was discussed, so focus on fixing the result.
Last reviewed November 9, 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 →
