A Practical Way for Solo Developers to Say Not Yet to Features

A good idea can still be a bad next task.

That is a useful distinction for anyone building software without a full product, support and QA team behind them. A feature request might sound reasonable, solve a real problem and fit the direction of the app. It can still absorb the time needed to fix a problem that is already affecting users.

A roadmap needs a place for ideas that deserve attention but do not deserve a promise. I like the idea of a plain-language 'not now' list. It is not a graveyard. It is a way of separating curiosity from commitment.

Start with the job, not the requested button

Feature requests usually arrive as solutions: add a toggle, make a dashboard, sync everything, integrate with another service. Before estimating work, translate the request into the user's underlying job.

Instead of 'add export presets,' try: 'People need to repeat the same export without rebuilding their choices.' That tells you what success would look like, and it leaves room for a smaller answer than the requested feature.

This is also where it is easy to get fooled by your own familiarity with an app. The developer sees a clean implementation challenge. The person using it sees a task they need to finish.

Write down the job in one sentence. If you cannot do that, the request probably needs discovery before development.

Ask what evidence you actually have

One detailed request is useful feedback. It is not a market estimate.

The person may be describing a frequent obstacle, or they may have a specialized workflow that few others share. That uncertainty is normal. What matters is keeping it visible.

A small evidence card can include where the request came from, whether it is repeated, whether there is a credible workaround, and what happens if you do nothing this month. Use 'unknown' rather than filling gaps with guesses about demand.

The wrong answer is to publicly announce a feature because a single conversation made it feel urgent.

Price the maintenance, not just the build

A feature can be a weekend to implement and a recurring obligation for years. Ask what it adds to setup, testing, documentation, permissions, accessibility, troubleshooting and migration when underlying APIs change.

Consider a preference that changes where files are saved. The implementation might be short, but support now has to explain where files went, handle unavailable destinations and verify older preferences after an update.

Those costs are real even when there is no invoice for them.

My preferred test is simple: if a feature ships, what new question will the person maintaining the app have to answer every release? If the answer is unclear, research it before promising a delivery date.

Look for the reversible version

A feature request is less risky when you can test its usefulness without redesigning the application.

Sometimes a guide, a sample workflow, a better default or a small optional setting can answer the underlying problem. That does not mean documentation should hide a broken experience. It means the smallest honest solution is worth considering before a permanent new subsystem.

For experimental ideas, define what you would learn and what would make you stop. A prototype is not an announcement. A private test is not a public beta. A roadmap item is not a release date.

Make 'not now' an actual decision

Each deferred item should have a reason and a trigger for revisiting it.

'Not now because it creates new file-location behavior and we have not verified demand' is useful. 'Maybe later' is not. The first sentence can guide future work and explain the decision to a user without sounding dismissive.

A simple decision record works:

Problem: What does the user need to do?

Evidence: What have we seen, and what remains uncertain?

Cost: What changes after the feature exists?

Alternative: Is there a smaller reversible option?

Revisit when: What new evidence would change this priority?

The record does not need to become a planning ceremony. Five useful lines beat a crowded feature board that nobody trusts.

Protect the part of the app that already works

Solo development rewards focus because every new capability competes with reliability. It is tempting to measure progress by release-note length. People usually experience progress when their normal work becomes more predictable.

That might mean keeping a feature off the roadmap for another month while fixing a confusing prompt, an inconsistent state or a silent error. Those improvements rarely look exciting in a roadmap screenshot. They can be the difference between software someone tries once and software they keep.

Saying 'not now' is not the opposite of building. It is part of making sure the next thing you build earns its place.

Your Turn: What's on Your Not-Now List?

Take a look at your backlog and pick one feature request you've been putting off. Write down why it isn't a priority right now and what would need to change for you to reconsider it.

If you're building an app, I'm curious: What's one feature you've deliberately decided not to build yet, and why?

Drop it in the comments. I'd love to hear how other builders make those decisions.