Saying No to Feature Requests | Coding Capybaras

Photo by Nadine E on Unsplash

Saying no to feature requests is the founder skill I was worst at and needed most. The honest answer to "how do you decide what to say no to" is that you say no to almost everything by default, and you say yes only when a request lines up with the product you already decided to build. That sounds harsh until you watch the alternative play out: a product that does forty things adequately, a codebase you can no longer reason about, and a roadmap set by whoever emailed you last. This post is the specific requests I turned down building Coding Capybaras, the two nos I actually regret, and the scripts I use so a no doesn't cost me the relationship.

TL;DR

• Say no by default. A feature request is a data point about a problem, not an instruction to build the solution the customer imagined.
• Most nos should be strategic nos — "this doesn't fit the product" — not resource nos or technical nos.
• "No now" and "no forever" are different answers. Say which one you mean, and briefly explain the thinking. People forgive a clear no; they resent a vague maybe.
• Never chase the "I'd sign up if you only had X" customer. That request is a trap disguised as a sale.
• The requests I regret saying no to were the boring infrastructural ones I dismissed as "not the vision." Watch for that bias.

Why saying no is the whole job

When I shipped the first version of Coding Capybaras, I was flattered by every feature request. Someone using the thing enough to want it to be different felt like proof it mattered. So my instinct was to say yes, or worse, to say "great idea, I'll look into it" and mean nothing by it.

That instinct is how good products die. The 37signals team — the people behind Basecamp and the book Getting Real — have a whole chapter titled "Forget Feature Requests," and their argument stuck with me: the requests you can't forget are the ones worth building. The rest are noise you don't need to file, track, or feel guilty about.

Here's the reframe that finally worked for me. A feature request is not a spec. It's a customer telling you about a problem, wrapped in their guess at the solution. The problem is often real. The solution they proposed is often wrong for everyone except them. Your job is to separate the two — to hear "I need to see project timelines" and not automatically build the Gantt chart they asked for.

Jason Fried put the extreme version of this plainly in an old Signal v. Noise post: "I know we will never add Gantt charts to Basecamp. You can send 100 requests on it and we're just not going to go that way." That's not stubbornness. It's a product that knows what it is. A hundred requests for a thing that contradicts your product's reason to exist is still a no.

Saying no is not the thing you do instead of building the roadmap. Saying no is building the roadmap. Every no is a vote for the small number of things you decided actually matter.

The four kinds of no

Not all nos are the same, and confusing them is how founders end up either bloated or defensive. I sort every request into one of four buckets before I reply.

| Type of no | What it means | How I say it | | --- | --- | --- | | Strategic no | The request contradicts the product I'm building | "We're not going that direction, and here's why" | | Resource no | Good idea, real value, but I can't build it now | "I like this. It's not something I can take on this quarter." | | Technical no | The request fights the stack or the architecture | "This would mean rebuilding X, so I'm not going to" | | Temporary no | Reasonable, on the maybe-pile, no promises | "Noted and genuinely considered — no commitment on timing" |

The mistake I made early was dressing up strategic nos as resource nos. Telling someone "I don't have time right now" when the truth is "I'm never building this" feels kinder in the moment. It isn't. It leaves the door open, so they ask again in three months, and now you've trained them to expect a yes that will never come.

Most of your nos should be strategic. If most of your nos are resource nos, your product hypothesis is too weak — everything feels plausible because you never decided what the product isn't. A clear product vision is mostly a list of things you've already ruled out.

The temporary no is the trickiest, because it's real but easy to fake. 37signals is honest that a huge share of what they eventually build started as a customer request — Fried says roughly nine out of ten things they add began that way. So the maybe-pile is not a graveyard. But a temporary no only works if you actually revisit it. If "we'll consider it" is a lie you tell to end the conversation, customers can smell it, and it does more damage than an honest no.

The requests I turned down (and was right to)

A few concrete ones from the last year, because "say no more" is useless without examples.

The all-in-one request. Early on, a handful of people wanted Coding Capybaras to also be a CRM, a help desk, and an analytics suite. Each ask was reasonable on its own. Together they described a different, worse product. Coding Capybaras is a SaaS boilerplate for non-technical founders shipping with AI. The moment it becomes a platform-of-everything, it's good at nothing and impossible to maintain solo. Strategic no.

The one-customer config. Someone wanted a deeply specific workflow that fit exactly their business and no one else's. This is the most seductive request, because there's a real, paying human on the other end. But building it means carrying that complexity forever, for one person. I've written before about why most boilerplates fail non-technical founders — and it's almost always because they said yes to too many one-customer configs until the "starter" was a maze. Strategic no, with a suggestion for how they could build it themselves on top.

The "I'd buy it if" pitch. A few times someone said they'd upgrade to Pro if I added a specific integration. Fried's warning is exactly right here: "Don't chase customers who make specific demands like this. 'I'd sign up if you only had this that or the other.' Dangerous ground." I chased one of these once. Built the thing. They didn't buy. The demand was never really about the feature.

The pattern across all three: the request pointed at their situation, not at a problem shared by the people I'm building for. That's the tell. A request that would help one loud customer is a no. A request that quietly keeps showing up from many customers is a signal.

flowchart TD
    A[Feature request arrives] --> B{Does it fit the product<br/>I decided to build?}
    B -->|No| C[Strategic no —<br/>explain the direction]
    B -->|Yes| D{Do many customers<br/>hit this same problem?}
    D -->|No, just this one| E[Temporary no —<br/>add to maybe-pile]
    D -->|Yes| F{Can I build it<br/>without breaking the core?}
    F -->|No| G[Technical no —<br/>say what it would cost]
    F -->|Yes| H[Candidate for the roadmap]

The two nos I regret

This is the part most "say no to everything" posts skip, and it's the part that matters.

The requests I regret declining were not the exciting ones. They were the boring, infrastructural asks that I dismissed because they didn't feel like "the vision." Two specifically.

First: a couple of early users asked for clearer documentation on the sync workflow between the boilerplate and their own fork. I filed it under "not a feature" and moved on. Wrong call. It wasn't a feature request — it was a symptom of a real gap that generated support tickets for weeks. When you're doing founder-led support, the requests that come back as repeated tickets are the roadmap, whether or not they look like features. I eventually built the docs. I should have done it the first time someone asked.

Second: someone requested a simpler way to see what changed between boilerplate versions. Felt like a nice-to-have. It was actually a trust issue in disguise — people were nervous about pulling updates because they couldn't see what they were pulling. A no on the surface feature was a no on the underlying trust. That's the expensive kind of mistake.

The bias to watch for: founders over-value the requests that flatter our vision and under-value the ones that sound like chores. The unglamorous asks — docs, exports, clearer errors, better onboarding — are frequently the ones that decide whether people stay. I've written about the unglamorous truth of indie SaaS elsewhere, and this is a slice of it: the boring request is often the important one.

How to say no without losing the person

A good no protects the relationship even when it disappoints. The rules I follow:

Be clear about which no it is. "No forever" and "no for now" require different words. Fried's line is the standard I hold myself to: "No now may be yes later. Or it may be no forever. The trick is to figure out which camp a certain no falls into and then respond appropriately."

Explain the thinking, briefly. Not a paragraph of justification — one or two sentences on the direction. "We're keeping Coding Capybaras focused on the core boilerplate rather than becoming an all-in-one, so I'm not going to add a built-in CRM." People accept a no far more easily when they can see it came from a decision, not a mood.

Never fake the maybe. If it's a no forever, say no forever. A canned "we'll consider it" reads as exactly what it is. One commenter on that same 37signals thread called it "a polite version of buzz off," and they were right.

Point to the alternative when there is one. Sometimes the answer is "not in the product, but here's how you'd do it yourself" or "here's a tool that already does this well." Being honest that another product is better for their specific need builds more trust than pretending you'll eventually cover it.

Say no fast. A quick, kind no respects the person's time. A slow no — weeks of silence followed by a soft brush-off — is the version that actually burns goodwill. This connects to a broader lesson from the week I almost gave up: most of the weight founders carry is self-imposed, and an unanswered inbox of requests you're afraid to decline is a large chunk of it.

Frequently asked questions

How do I say no to a feature request without losing the customer?

Be clear about whether it's a permanent no or a "not now," give one or two sentences of honest reasoning, and respond quickly. Most customers accept a no that's direct and explained. What loses them is a vague maybe that strings them along, or silence.

Should I keep a public roadmap so people can see what I said no to?

A public roadmap or feedback board helps, because it turns "no" into "here's what we're doing instead" and lets you point requesters at what's actually planned. The tradeoff is that a public board invites more requests and can create pressure to build by popularity rather than strategy. For a solo founder, a lightweight version — a short "what we will and won't build" note — often beats a full voting board.

How many feature requests should actually make it into the product?

There's no magic ratio, but the default should be "very few." Most requests are either one-customer configs or restatements of problems you're already solving. The ones worth building are the problems many customers hit repeatedly — which usually show up as recurring support tickets, not one-off emails.

What's the difference between a feature request and real product feedback?

A feature request proposes a specific solution ("add Gantt charts"). Real feedback describes a problem ("I can't tell what's blocking the project"). The problem is the valuable part. Your job is to extract it and decide whether the best fix is the one they suggested, a different one, or nothing at all.

Is it bad to tell a customer another product is better for them?

No — it's one of the most trust-building things you can do. If someone's need genuinely falls outside what you're building, pointing them to a better fit shows you're optimizing for their outcome, not your revenue. They remember that, and they often come back or refer others.

Learning to say no is learning what you're building

The reason saying no is hard isn't that we lack the words. It's that every no forces you to admit what your product is not — and that admission feels like closing doors. It is closing doors. That's the point. A product is defined at least as much by what it refuses to do as by what it does.

I'm still not great at this. I still feel the pull to say yes to the flattering request and the plausible one. But the discipline has made Coding Capybaras a clearer, more maintainable thing than it would have been if I'd built everything people asked for. The nos I regret taught me the one exception worth holding onto: the boring, repeated request is usually the real one.

I write about this stuff — the product decisions, the mistakes, the founder-brain of it all — every week on the Coding Capybaras blog. The boilerplate itself is free if you want to see what saying no looks like in an actual codebase.