As a gateway or platform team, you get feature requests from multiple teams all the time. Everyone has a use case. Everyone has a deadline. If you try to say yes to all of them, you end up busy, scattered, and eventually in a worse place than when you started.
Knowing when to say no is not about being difficult. It's about protecting your platform, your team, and in the long run, the same clients who are asking. Here's how I think about it.
Why always saying yes backfires
Every request has a cost — design, implementation, testing, docs, support. If you take everything, you're constantly context-switching. You never get to finish one thing well before the next one lands. The result is half-built features, delayed releases, and a team that's always firefighting. The business impact of "we did a little bit of everything" is often lower than "we did a few things really well."
Ad-hoc features tend to be bolted on. Special cases, one-off configs, branches in the code for "team X's workflow." Over time the codebase becomes a patchwork of exceptions. The next request is harder to implement because you're working around the previous ones. Saying yes today can make every tomorrow more expensive.
A platform that tries to be everything for everyone often ends up being confusing, inconsistent, or fragile. One team's custom behavior can break another team's assumption. A feature that "only affects one client" can still change global behavior — timeouts, retries, routing. The more special cases you add, the harder it is to reason about production. In the worst case, a niche feature causes an outage that affects everyone.
Some requests help one team once. Others, if you abstract them right, help many teams for a long time. If you don't distinguish, you spend most of your time on the former. Your impact stays local instead of platform-wide.
Why saying no can be the right call
Saying no is not rejection for its own sake. It's a way to:
- Your team can go deep on the things that matter most — reliability, performance, clear APIs — instead of spreading thin.
- When you say no to a one-off, you create space to ask: what's the underlying need? Can we solve it with a general mechanism instead of a custom feature?
- If you're clear about what's in scope and what isn't, teams can plan. They can build on top of your platform in ways that don't depend on you saying yes to every request. That's healthier than a backlog of "maybe someday" items that never get done.
- Fewer special cases mean fewer failure modes. A simpler platform is easier to operate and easier to reason about when something goes wrong.
When to say no
We used to have a naive rule: if more than two customers ask for the same feature, we put it on the roadmap. That didn't work. It ignored impact, effort, and whether the feature had a chance to be widely useful. Two teams asking for slightly different variants of "custom header handling" might be better served by one well-designed abstraction than by two separate features.
If the request is highly specific to one team's workflow and doesn't map to a pattern others will need, we tend to say no. We'd rather invest in a platform that lets teams tailor their own behavior — configuration, extensions, self-serve tooling — than hand-hold every unique use case. Your job as a platform is to provide the building blocks, not to be the custom dev shop for each client.
If building the feature takes a lot of time and only helps one or two teams, or if it's unlikely to be adopted more widely, we question it. Sometimes the answer is still yes (e.g. strategic partner, critical path). But often it's a signal that we should look for a more general solution or let the team solve it on their side.
Some requests push the platform toward more complexity or inconsistency. If we're trying to simplify, deprecate legacy behavior, or move toward a clearer model, we say no to features that pull the other way. Consistency and long-term health beat short-term accommodation.
When yes might be right
Saying no by default doesn't mean never saying yes. We say yes when:
- The request aligns with a common pattern we already want to support, or when it's the second or third time we've seen the same need (and we're building the abstraction, not the one-off).
- The impact is high — many teams, or a critical use case — and the effort is reasonable.
- Saying no would block important work and there's no good self-serve path yet. In that case we might do it once while we plan a better, general solution for the next time.
The key is to treat each yes as a deliberate choice, not the default.
Build for patterns, not for concrete problems
The takeaway we keep coming back to: try to abstract common patterns from concrete problems, and build solutions around those patterns.
When a team asks for "support for X in scenario Y," ask what X and Y have in common with other teams' needs. Maybe the right answer is a generic mechanism — a hook, a policy, a configurable behavior — that several teams can use in their own way. That's more work up front and often requires saying no to the "just do this one thing for us" version. But it pays off: one well-designed feature that serves many use cases beats five one-off features that only serve one client each.
Summary
You have many clients and many feature requests. If you always say yes, you burn out your team, pile up technical debt, and risk the stability and clarity of the platform. Knowing when to say no lets you stay focused, build for leverage, and keep the platform simple enough to run and evolve.
Say no to ad-hoc, one-team-only requests when you can offer a path to self-serve or a general solution instead. Say no when impact and adoption don't justify the effort. Say yes when it fits the platform's direction and helps many teams. And whenever you can, build for the pattern, not for the single request.