One request shows up in almost every product's inbox in some form, phrased as a small ask
A single new setting is never actually small once you count what it does to every screen and every support reply after it
I have three questions a request has to survive before it gets a yes, and most do not clear the first one
Saying no on purpose, in public, is what keeps four small tools feeling like one studio instead of four different opinions
The Request That Shows Up in Every Inbox
Across Git Dojo, OhNine, Statusline Builder, and Claude Blueprint, one request keeps showing up in slightly different clothes. Someone likes the tool, uses it daily, and asks for a toggle. Turn off this panel. Let me rename that label. Give me a setting to change the default. It always sounds small when it arrives, because from the outside it looks like one checkbox.
I used to say yes to almost all of these. Early on, every request felt like a vote of confidence, proof that someone cared enough about the tool to want it slightly different, and turning that down felt like turning down the person. So I added the setting. Then another person asked for the opposite setting, and I added that too, because refusing the second person after saying yes to the first felt inconsistent. Within a few months a tool that used to have one obvious way to work had six paths through it, and I was the only one who remembered which combination of settings caused which edge case.
The pattern is specific enough that I can name it now: it is almost never a request for a feature. It is a request to move a decision I already made back onto the user, one setting at a time. I wrote about the sentence-level test I run before an idea even gets a build slot in the first place, and this is the mirror image of that same discipline, applied after launch instead of before it. Deciding what to build is one filter. Deciding what stays fixed once it is built is a second one, and it turns out to be just as important.
What makes this request hard to say no to is that it is never wrong on its own terms. The person asking has a real workflow, and the current default genuinely does not fit it. I am not disputing that. What I am disputing is the assumption, mine as much as theirs, that the right fix is always a new setting rather than a better default, a clearer explanation, or sometimes just an honest no.
I also had to notice my own bias toward saying yes, because it is a flattering bias. Every request is proof someone read the interface closely enough to know exactly what they wanted different, and that kind of attention is rare and genuinely nice to receive. It is easy to let that good feeling stand in for a real evaluation of the request itself, and for a while I did exactly that, treating enthusiasm from the person asking as evidence the change was worth making, which is a different thing entirely.
Why "Just Add a Setting" Is Never Free
The cost of one setting is never the setting. It is everything that has to know about the setting afterward. A toggle in Git Dojo means two states to test instead of one, two states to describe in the help text, two states someone can end up in without remembering how they got there, and two states I have to hold in my head every time I touch that part of the code six months later.
Multiply that by a handful of settings and the tool stops having a single shape. It has a shape per user, quietly, and nobody chose that on purpose. The interface that looked simple in a screenshot stops matching what any individual person actually sees, because their combination of toggles is theirs alone. Support gets harder in a specific way here too: someone describes a bug, and the first question is no longer "what happened" but "what does your setup even look like right now," which is a bad question to have to ask about a tool that is supposed to save time, not add a second thing to configure.
There is a quieter cost that took me longer to notice, which is what it does to the next decision. Once a tool has three settings that exist because three different people asked, the fourth request stops looking unreasonable by comparison. The bar for "just add a toggle" gets lower every time it gets crossed, not higher, because the tool no longer has a strong existing shape to compare the new ask against. The same discipline that keeps five separate products from quietly merging into one bloated platform is the discipline that has to apply inside a single product too, or it drifts into the same mess one setting at a time instead of one product at a time.
None of this means every request is bad. It means the true cost sits downstream of the moment someone asks, and if I only weigh the moment itself, I will say yes far more often than the tool can actually absorb.
The clearest way I have found to explain this to myself is to picture the setting a year out, not the day it ships. A toggle I add today is not a toggle I remove tomorrow, because someone out there is now depending on whichever value they picked, and removing it breaks their setup for a reason they will not immediately understand. A setting is close to a permanent commitment dressed up as a small, reversible one, and treating it that way from the start changes how carefully I evaluate the request in front of me.
What I Say Instead
A request has to survive three questions before it turns into a setting, and I ask them in order because each one is cheaper to answer than the next.
The first question is whether the current default is actually wrong, or just different from what one person expected. Those are not the same problem. If three unrelated people hit the same friction independently, that is a signal the default itself needs to change, for everyone, with no toggle involved. Git Dojo's practice-repo reset behavior changed this way once, from a request that looked like "let me configure the reset," and the actual fix was making the default smarter, which meant nobody needed a setting at all, including the person who asked.
The second question is whether there is already a way to get the same outcome that the person simply has not found yet. This one comes up more than I expected. Half of what looks like a missing feature is a missing sentence in the documentation, and writing that sentence costs a few minutes instead of a permanent branch in the code that I now maintain forever.
The third question, and the one that actually filters most requests out, is whether the ask is specific to one workflow rather than a shape the whole tool should have. If the honest answer is "this genuinely only makes sense for what I use it for," I say so, plainly, and explain why. Most people take that well when it is explained rather than just refused. What people do not take well, and rightly so, is silence, or a vague "maybe someday" that never resolves either way. A clear no with a reason costs less trust than a request that quietly disappears into a backlog nobody reads.
When a request does clear all three, it usually is not a setting anymore by the time it ships. It is a default that got better for everyone, which is a different, better outcome than the one that was originally asked for.
I try to answer every request with all three questions spelled out, even the ones I turn down, rather than a flat no with no reasoning attached. It takes longer to write than "not planned," but it means the person on the other end understands the actual bar, and more than once someone has come back later with a sharper version of the same request that clears it. The three questions are not just a filter for me, they are a shared standard the person asking can check their own idea against before they even send it.
The One Time Saying Yes Was the Right Call
I do not want to make this sound like a rule with no exceptions, because it is not, and the one clear exception taught me most of what I know about where the line actually sits.
OhNine started as a strict, opinionated menu bar view of usage limits with exactly one layout, on purpose, because I did not want it to become a dashboard with knobs. The reasoning behind that opinionated default is the same one I wrote about when I explained why I built it in the first place. One request kept coming back anyway, not about the layout, but about when the numbers refreshed. People running long sessions wanted a shorter interval than the default, and the request was not "give me a dashboard," it was one specific, repeated, well-described problem hitting a real number of people the same way.
That one passed all three questions cleanly. The default really was wrong for a common, specific pattern, not just one person's taste. There was no workaround hiding in the existing interface. And the ask was not really about personal preference, it described a shape the tool should have handled from the start. So it became a setting, a single one, with a sensible range instead of an open text field, which kept it from becoming the kind of unbounded knob I usually avoid.
The lesson was not "say yes sometimes to be nice." It was that the three questions work precisely because they let a genuinely good request through cleanly, while stopping the far larger number of requests that only look similar from the outside. Saying yes to the right one is easy once saying no to the rest has already done its job.
Bottom Line
The instinct to say yes to every request that sounds reasonable is not a bad instinct on its own. It comes from genuinely caring whether the tool fits the person using it. But caring about fit and adding a setting are not the same move, and treating them as the same move is how a clean, opinionated tool turns into six different tools wearing one interface.
Saying no, out loud, with a real reason, is the harder version of caring about the same person. It protects the shape that made the tool worth using in the first place, for them and for everyone who has not asked yet. The one exception that gets through, the one that survives all three questions, tends to be a real improvement precisely because it was tested against a bar high enough to stop the rest.
I would rather explain a clear no than maintain a setting nobody remembers the reason for. That trade gets easier every time I actually make it.
Top comments (0)