When to Say No to a Feature Request
The most expensive thing on most websites isn't the design or the hosting. It's the accumulated weight of features that were requested once, built dutifully, and used briefly.
The members area with four members. The event calendar last updated in 2023. The three-step quote calculator that everyone abandons at step two and calls instead.
Each is code that must be maintained, updated, secured, and worked around forever.
Why "yes" is the default
Saying yes is easier for everyone in the moment. The client feels heard, the agency gets paid, the developer has clear work. The cost lands later, distributed across every future change, invisible to the person who approved it.
That's a bad incentive structure, and the antidote is a habit of asking a few questions before agreeing.
The questions
What are you actually trying to do? Nearly every feature request is a proposed solution in disguise. "We need a chatbot" is often "people ask us the same four questions and we're tired of answering." That's an FAQ, not a chatbot — and it can ship this week.
How will we know it worked? If nobody can name a number that should move, there's nothing to evaluate, which means it will never be removed either.
What is the manual version? Almost anything can be done by a person before it's automated. If the manual version isn't worth someone's time, the automated version probably isn't worth building.
Who maintains it? Content-driven features need a content owner. An event calendar without someone whose job includes updating it becomes a public record of neglect.
What does it cost if we don't? Sometimes the honest answer is "nothing measurable," and that's a fine reason to skip it.
How to say no well
Not "no." Say what you'd do instead, and why.
"We could build the calculator — it's about three weeks and it'll need maintaining as your pricing changes. Or we could put your three most common package prices on the page this week and see whether people still call for a quote. If they do, the calculator's clearly worth building and we'll know what to put in it."
That version is a service. It gives the client a cheaper path to the same outcome and a real decision to make. In our experience most people take the smaller option, and a good share of the time it turns out to be sufficient.
The ones to say yes to quickly
Anything that removes friction from a customer contacting you. Anything that fixes something broken. Anything that makes the site faster or more accessible. Anything the owner needs in order to update their own content.
Those compound. Features rarely do.
The annual subtraction
Once a year, list every feature on the site and check what it's been used for in the last twelve months. Remove what isn't earning its keep.
It is the least popular meeting of the year and reliably the most valuable one. A website that does five things well beats one that does twenty things adequately — and it costs far less to keep alive.