"Can you just add..."

These four words have caused more damage to products than any technical debt.

The feature request seems small. A few hours of work, maybe. The user asking is enthusiastic. They really want this. It would make them happy.

So you say yes.

And then you say yes again. And again. And again.

Twelve months later, your product is bloated, confusing, and exhausting to maintain. You've lost what made it special.

The Visible Costs

When you evaluate a feature request, you naturally think about:

Development time. How long will it take to build?

Testing time. How long to make sure it works?

Documentation. What needs to be explained?

These are the obvious costs. They're also the smallest ones.

The Hidden Costs

Here's what you're not accounting for:

Maintenance forever. Every feature you add is a feature you support forever. Updates, compatibility checks, edge cases—forever.

Bugs in new surface area. More code means more places for things to break. More features means more bug reports.

Complexity for users. Every feature is another option, another button, another thing to understand. Cognitive load increases with every addition.

Cognitive load for you. You have to remember how everything works. Every feature lives in your head forever.

Edge cases you didn't anticipate. Features interact. The new feature breaks something old. The edge case you didn't test appears in production.

Documentation and support. Every feature generates questions. "How do I use this?" "Why does this do that?"

The Compounding Problem

One feature is manageable.

Ten features is 10 things that can break, 10 things to explain, 10 things to maintain.

But it's worse than that. Features interact.

Feature A might work fine. Feature B might work fine. But A and B together might have unexpected behavior. Now you're debugging interactions you never anticipated.

This compounds. Forever.

How to Evaluate Feature Requests

Before you say yes, ask:

Does this help the core use case? Is this what the product is for? Or is it adjacent, nice-to-have, outside the core value proposition?

Is this a pattern or a one-off? One person asking is an opinion. Multiple people asking independently is a pattern.

What's the maintenance burden? Not just build time—forever time. How much will this cost you in perpetuity?

What won't you build if you build this? Every yes is a no to something else. What's the opportunity cost?

The Art of Saying No

Most feature requests should be declined. Not harshly—gracefully.

"Great idea—not something we're focused on right now."

"We're keeping the product simple intentionally."

"That's on our radar for future consideration."

Users respect focus. They respect products that know what they are and what they're not.

The best products say no more than they say yes.

The Simplicity Premium

Simple wins.

Simple products are easier to use. Users understand them faster, get value sooner, stay longer.

Simple products are easier to maintain. Less code, fewer bugs, less time spent on upkeep.

Simple products often win. The bloated incumbent loses to the focused challenger.

Your simplicity is your advantage. Don't give it away one feature at a time.

Related Reading