Handling Feature Requests When You're the Only Developer

Photo by sorour mahboubifard on Unsplash

When you're the only person who can build the thing, every feature request is a small negotiation with your own week. A feature request process for a solo founder isn't a product committee — it's a durable place to capture requests, a fast way to score them, and a habit of closing the loop so people know they were heard. The goal isn't to build more; it's to build the right few things without drowning in a backlog you'll never clear or, worse, saying yes to everything and shipping a bloated product nobody can navigate. This is the system I use to handle feature requests without a product manager, a roadmap tool suite, or more than a couple of hours a week. It has three parts: capture, triage, and the honest no.

TL;DR

• Capture every request in one durable place, not scattered across email, chat, and your memory. A request you can't find is a request you can't prioritize.
• Score with the impact/effort matrix — fast and good enough for a solo founder. Reach for RICE only when you have real usage data to plug in.
• Run a short triage weekly (or twice a week if volume is high). Consistency beats sophistication.
• Say no by default, and say it clearly. "You rarely regret saying no, but you often wind up regretting saying yes."
• Close the loop. A visible response — even a "not now, here's why" — teaches customers their feedback is read.

Capture: one place, or it doesn't count

The first failure mode isn't saying yes too often. It's losing track. Requests arrive through support email, a reply on X, a Slack DM, a line buried in an onboarding call. If they live in seven places, they live nowhere, and you end up prioritizing by whoever emailed you most recently — which is the opposite of prioritizing.

So the first rule is boring: every request goes to one durable place. That can be a public feedback board, a private database, or even a single well-structured note — the tool matters far less than the discipline of routing everything into it. When a request comes in through support, you thank the person and log it. When it comes from a call, you write it down before the next thing. The channel of arrival stops mattering the moment it's captured.

A public or semi-public board has a specific advantage worth calling out: it lets users search existing ideas, vote, and comment, which cuts down on duplicate requests and does some of your triage for you. When ten people upvote one idea instead of ten people emailing you the same idea separately, you've learned something about demand for free. It also sets up the loop-closing you'll do later, because the request already lives somewhere the requester can check back on. The tradeoff is that a public board is a commitment — a graveyard of ignored requests is worse than no board at all. If you can't tend it, keep capture private until you can.

Whatever you choose, capture the same three things every time: what they want, why they want it (the underlying problem, not the proposed solution), and who asked. That "why" is the most valuable field on the form. Founders who chase the literal request build the wrong thing; the person asking for a CSV export usually wants to get their data into a spreadsheet, and there may be a better answer than a CSV export. This is the same instinct that makes founder-led support so useful early on — you're close enough to the customer to hear the problem under the ask.

Triage: a rhythm, not a reaction

The second failure mode is triaging in real time. A request lands, it feels urgent, you drop what you're doing and build it. Do that a few times and your roadmap is just an inbox with extra steps.

The fix is a rhythm. Set a recurring block — weekly if request volume is low, twice a week if it's high — where you sit down with the captured list and do nothing but sort. The value of a fixed cadence is that it takes the urgency out of any single request. Nothing has to be decided the moment it arrives, because there's a known point, soon, when it will be decided. That alone kills most of the reactive thrash.

In that block, you're not building and you're not writing long replies. You're sorting each new request into a small number of buckets: do it soon, plan it for later, not now, and never. The "never" bucket is not cruelty — it's focus, and you'll communicate it kindly. The point of triage is to move every open request out of limbo and into one of those states, with a one-line reason attached. A request that's been sitting untouched for a month isn't "under consideration"; it's a decision you haven't made yet. Make it.

This cadence pairs naturally with the other weekly rhythms of running a small SaaS — the same standing block that produces your changelog and release notes can end with ten minutes of request triage. Batching the product-thinking work keeps it from bleeding into every hour of your week.

Scoring: the impact/effort matrix beats guessing

Sorting requests into buckets is easier when you have a consistent way to compare them. The heavyweight answer is RICE — Reach, Impact, Confidence, Effort — a scoring model developed by the product team at Intercom that multiplies reach, impact, and confidence, then divides by effort. It's a genuinely good framework. It's also more than a solo founder usually needs, because three of its four inputs require data you may not have yet.

For most of us, the fast version is enough: a two-by-two of impact against effort.

You plot each request by how much it helps (impact, roughly: how many customers, how much pain removed) against how long it'll take you (effort). The quadrants sort themselves. Low effort and high impact — the top-left — you do now; these are the wins that make customers feel heard for a day of work. High effort and high impact you plan deliberately, because they're real projects. Low effort and low impact you batch for a rainy afternoon. High effort and low impact — the bottom-right — you say no to, every time, no matter how politely it was asked.

The matrix's virtue is speed. You can place a request on it in seconds, and you don't need usage analytics to do it — just judgment, which as the founder you actually have. Graduate to RICE later, when you've got real numbers from your analytics and metrics to plug into the reach and confidence fields. Until then, don't let the perfect scoring model stop you from using the good-enough one. A request scored roughly today beats a request scored precisely never.

One honest caveat: your effort estimates will be wrong, especially early, and especially for anything touching auth, billing, or data models. When in doubt, bump the effort score up a notch. The cost of underestimating a "quick" feature that turns into a two-week yak-shave is higher than the cost of deferring something that would've been fast.

The public roadmap question

At some point you'll wonder whether to make your roadmap public. It's a real decision with real tradeoffs, and the honest answer is "it depends on whether you can maintain it."

The case for going public is strong. A visible roadmap builds trust — customers see their requests are tracked, and prospects see the product is alive and moving. It reduces duplicate requests, because people check the board before asking. It's a quiet sales asset, giving you an easy answer to "are you building X?" And it aligns expectations, which reduces the churn that comes from someone assuming a feature is coming next week when it's six months out. Those benefits compound with the build-in-public approach a lot of indie founders already lean on.

| Consideration | Public roadmap | Private roadmap | | --- | --- | --- | | Customer trust | High — visible progress | Lower — they take your word | | Duplicate requests | Fewer — people check first | More — no shared view | | Sales usefulness | Answers "are you building X?" | Handled case by case | | Flexibility to change | Constrained by public promises | Full — nobody's watching | | Maintenance burden | Real — a stale board hurts you | Minimal |

The case against is quieter but worth respecting. The competitive-risk worry — someone stealing your ideas — is mostly overblown; execution and communication are the moat, not the feature list. The real cost is commitment. A public roadmap creates expectations, and a solo founder's plans change constantly. The safe version is to publish direction, not dates: broad "now / next / later" columns without hard timelines, so you keep the trust benefit without promising a ship date you'll miss. And an abandoned public board actively damages trust, so only commit to one you'll actually tend during your weekly triage. When in doubt, start private and go public once your cadence is solid.

Saying no: the skill that protects the product

Here's the part that's hardest for founders who got into this to make people happy: most requests should get a no. Not a rude no, not a silent no — a clear, kind, honest one. The team at 37signals, who've run this playbook for two decades, put it bluntly: they say no to just about everything by default, while still reading and considering every suggestion. Their line from Rework is the one I keep taped to the metaphorical wall: "You rarely regret saying no, but you often wind up regretting saying yes."

The reason no is the default isn't laziness — it's that every yes is permanent. A feature you ship is a feature you maintain, support, document, and carry forward through every future change. The feature requests I've turned down were rarely bad ideas; they were good ideas that would've made the product heavier for everyone to serve a few. Saying no is how you keep the thing simple enough that your AI assistant, your support load, and your own brain can still hold all of it.

The trick is that a good no still closes the loop. The worst outcome isn't declining a request — it's silence, which teaches customers that feedback vanishes into a void. So even a no gets a response: acknowledge the request, give the real reason ("this would help a small number of accounts and take weeks I'd rather spend on reliability"), and where you can, offer the workaround that solves their actual problem today. Moving a stale request to "not now" with a visible reason does the same job at scale — it shows the board is read. Here's the template I use:

Thanks for this — I logged it. Right now it's a "not now" for me: it'd take a few weeks and would mostly help accounts doing X, and I'm focused on Y this quarter. If you're trying to accomplish Z, here's a way to do it today: [workaround]. I'll revisit if more people hit the same wall.

That reply respects the person, tells the truth, and leaves the door open — without committing you to anything. It's the difference between a customer who feels ignored and one who feels heard even though they didn't get the yes. Handled well, a no can build more loyalty than a rushed yes, and it protects the onboarding simplicity that keeps new users from bouncing off a cluttered product.

Frequently asked questions

How often should I review feature requests as a solo founder?

Weekly is a good default; move to twice a week if request volume is high enough that a week's backlog feels unmanageable. The specific cadence matters less than having one at all — a fixed, recurring block removes the urgency from any single request, because there's always a known point soon when it'll be decided.

What's the simplest way to prioritize feature requests?

The impact/effort matrix. Plot each request by how much it helps customers against how long it'll take you, and the quadrants sort themselves: low-effort high-impact you do now, high-effort low-impact you decline. It's fast, requires no analytics, and is good enough for a solo founder. Graduate to RICE when you have real usage data.

Should I make my product roadmap public?

Only if you'll maintain it. A public roadmap builds trust, reduces duplicate requests, and helps sales — but a stale, ignored board damages trust more than having none. If you go public, publish direction ("now / next / later") rather than hard dates, so changing plans doesn't mean breaking promises. Start private if your triage cadence isn't solid yet.

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

Acknowledge the request, give the honest reason you're declining, and offer a workaround for their underlying problem where one exists. Silence is what upsets people, not a clear no. A response that says "not now, here's why, and here's how to solve it today" respects the person and often builds more loyalty than a reluctant yes.

What should I capture when someone requests a feature?

Three things: what they want, why they want it (the underlying problem, not just the proposed solution), and who asked. The "why" is the most valuable — it lets you solve the real need, which is often better served by something other than the literal feature requested.

Isn't saying no to most requests bad for retention?

Counterintuitively, no. Every feature you ship adds weight the whole product carries forever, and a bloated app churns users who can't find what they need. Saying no by default keeps the product focused, and closing the loop kindly on a declined request preserves the relationship. The 37signals playbook — decline most things, read everything, respond honestly — has sustained their products for twenty years.

Building the few right things

A feature request system for a solo founder isn't about processing more requests — it's about protecting the small number of hours you have to build, and spending them on the things that actually matter. Capture everything in one place, score it fast with the impact/effort matrix, triage on a rhythm instead of a reflex, and get comfortable saying a clear, kind no. The founders who ship focused products aren't the ones who say yes the most; they're the ones who chose well and closed the loop honestly on the rest.

If you're running a SaaS solo and want the operational scaffolding already built in — support, lifecycle email, and the admin tooling to actually act on what you learn — Coding Capybaras is the free boilerplate I built for exactly this kind of one-person operation.