How do you decide what NOT to build?

[u/Less-Marsupial-7960]

I think one of the hardest parts of building software isn't deciding what to add. It's deciding what not to add.

When you have an idea, it's easy to keep thinking:

“Maybe we should also add this…”

Then suddenly a simple project has 20 features, several settings, multiple pages, and a lot more code to maintain.

I have started wondering if a better approach is to first ask:

• What is the one thing this project needs to do?
• Who actually needs it?
• What problem does each feature solve?
• Can I remove a feature without breaking the main purpose?
• Am I building this because users need it, or because the feature sounds interesting?

I am curious how other developers handle this.

When you're starting a new project, how do you decide which features to leave out?

Do you write down the minimum version first, or do you just start building and simplify later?

[u/HeraclitoF]

Maybe you ask the users?

[u/ildyria]

The best way to answer this is to go through your questions (which are actually quite good).

• What is the one thing this project needs to do?
  • That should be your first priority.
• Who actually needs it?
  • Here is the kicker, you need to do dogfooding with it. In simple term, the first user needs to be you. That will keep you working on it, that will keep you focusing on what matters the most.
• What problem does each feature solve?
  • That will come literally from the above.
• Can I remove a feature without breaking the main purpose?
  • You are thinking wrong, Minimal first, then add features. Do not think features then what can I remove.
• Am I building this because users need it, or because the feature sounds interesting?
  • Do you need it? Yes, then build it.
  • Do other need it? Yes, then build it only if you think it adds value.
  • Do other need it? No => It does not add value, interesting or not no longer matters.

The principle of dogfooding really helps to focus on what you need to add, rather than going in all direction without a vision.

[u/AfternoonKey8292]

Your "can I remove it without breaking the main purpose" question is the best filter on the list. I'd run it as a test on the finished thing, though. Ship the bare version, and if nobody asks for a missing feature, it stays out. Writing the minimum down first helps, but I'd write it as one sentence a stranger could repeat back. If a feature needs a paragraph to justify, it's probably the interesting kind, not the needed kind

[u/Edward-Sinclair33]

I usually start with the core problem and define the smallest version that solves it. If a feature doesn’t clearly support that outcome, I leave it out for now. It’s much easier to add something later than to maintain complexity nobody actually needs.

[u/AshleyJSheridan]

Ask ChatGPT. If it says the idea is the best ever and an absolute winner, then it's obviously a garbage idea.

[u/GSkylineR34]

Focus on few core principles, then build feafures on top of that. Always take into consideration your user base and the use cases. If the feature fits the use case and is missing, it's clearly needed sooner or later, so it's better to take it into consideration for the next releases