Client feature requests: when to say no to a custom build
How to handle client feature requests you shouldn't build: when to say no, when to say yes at a price, and the sentence that keeps the relationship intact.
The request arrives as a casual line in an email. "Could we add a little members' area?" "Is it possible to take bookings on the site?" "Can the homepage change depending on where people are?" Each one sounds small, and each one has a client behind it who's excited about the idea.
Most agencies say yes, because saying no feels like losing. Some of those yeses turn into the most expensive work they'll ever do.
The real cost of yes
A feature has two costs. There's the build, which you can quote. And there's the cost of keeping it working on that site for as long as the site exists, which almost nobody quotes.
That second cost is the one that hurts. Every custom feature has to be tested when the platform updates, explained to the next person on the client's team, fixed when an outside service changes its API and remembered when you redesign. Every plugin is a decision you have to keep making makes the point about plugins, and custom features are the same, with you as the vendor.
So when you price a yes, price both. If you can't price the second, that's a sign.
A triage test for client feature requests
Before you answer, sort the request into one of four kinds. It takes a minute, and it decides the reply.
It's content. The client can already do it. They want a new team member, a new service page or a changed opening time. Show them how, or point them at the guide in the handover. No build.
It's a new section type. They want something the site's section library doesn't have, like a pricing table or a timeline. That's a real but bounded piece of work: design it, build it once, add it to the library. Quote it.
It's a capability. Bookings, search, a newsletter signup, a second language. Before quoting a custom build, check whether the platform or an existing app already covers it. Often it does, and the job is configuration, not code.
It's a different product. A shop with stock control. A customer portal. A booking system with staff rotas and payments. These aren't features of a website. They're separate products, and the right answer is usually a referral to something built for the job.
Most requests are kind one or two. The expensive mistakes come from treating kind four as kind two.
Saying no well
A good no always comes with something attached: a better option, a price or a referral. A bare no damages the relationship. A no with a next step usually doesn't.
Here are three replies worth keeping.
"You can do this yourself already. Here's the two-minute version, and I've added it to your guide."
"That's a new section type, so it's a small build rather than an edit. It's £X and we can have it on staging within two weeks. Once it's built you can use it on any page."
"What you're describing is really an online shop, and the best tool for that is Shopify. We'd rather set you up with something built for selling than bolt a shop onto your site. We can link the two."
The third one is the hardest to send, and it's the one clients remember. You've told them the truth about their own project, and you've shown that you'd rather they got the right thing than that you got the work.
When to say yes
Say yes when one of two things is true.
It's reusable. If three clients have asked for it, or you expect them to, build it properly once and offer it to everyone. It becomes part of your product rather than a fork in one client's site. How to run a productised website service covers how that list grows.
The client pays for it properly. That means the build and an honest share of the upkeep, either as a higher care plan or as a line in it. A client who wants something unusual and pays what it costs is a good client. Our post on scoping a website project has the wording for putting upkeep in a quote.
If neither is true, it's probably a no, however friendly the request.
Where we say no ourselves
We apply the same test to our own product, and it means we turn some things down. There's no visual drag-and-drop canvas, because a canvas produces layouts only the canvas can read, and the client's editor would stop being safe to hand over. Why we don't have a drag-and-drop editor makes the argument. And there's no shop, checkout or payments. If a client needs real commerce, we'd tell you to use a platform built for it, the same way we'd want you to tell your client. Saying no will cost us some customers. We think it's cheaper than becoming a product that does everything badly.
What it costs to say no
Some clients will hear no and go elsewhere. Occasionally that's a real loss: a good client, a good project, and a feature that would have been fine. Saying no also takes a confidence that's hard to find in a quiet month, when any work feels like good work.
The alternative is worse. An agency that says yes to everything ends up maintaining a portfolio of one-off features it can't update, each one a small liability with its name on it.
Write your three replies now
Don't wait for the next request. Write your own versions of the three replies above, in your own voice, with your own prices. Put them somewhere the whole team can find them. The next time a client asks for something you shouldn't build, the hard part, finding the words, will already be done.