The best feature is often the one you don't build
Clients ask for more, and saying yes feels good. But every feature you ship is a promise you have to keep forever - here's how we decide what actually earns a place in the product.
Saying yes feels like progress
Every client meeting eventually produces a wishlist: one more toggle, one more report, one more setting nobody has asked for twice. Saying yes feels generous, even smart - it looks like the team is responsive and the product is growing. But a feature list is not a scoreboard. Software does not get better because it does more. It gets better because it does the right things well.
A feature is never free after launch
The build is the cheap part. Every feature you ship has to be tested again with every future change, explained in onboarding, supported when it breaks, and carried through every migration for as long as the product lives. A setting nobody uses still shows up in the code, in the UI, in the support queue. Ten years later, someone is still paying for that yes.
The real question is not 'can we build it'
Almost anything can be built. The better questions are: who actually needs this, how often, and what happens if we simply say no? If the honest answer is 'one client asked once,' the feature is a favor disguised as a roadmap item. If three different clients keep hitting the same wall, that is a real signal, not a request - and it deserves a proper answer, not a quick toggle.
The ACS filter
Before we add anything, we ask what it costs to maintain, not just to build. A smaller product that does its core job cleanly beats a large one that does everything half-heartedly. Sometimes the best thing we do for a client is talk them out of a feature - and build the simpler version that actually gets used.