The slow death of simple software

One thing I’ve started noticing while building software is how easy it is for simple systems to slowly become complex.

It rarely happens because someone deliberately decides to make things complicated. More often it happens through a series of completely reasonable decisions. A user asks for something useful. Another user needs a variation of it. An edge case appears. Each step seems small and justified, but over time the system becomes heavier and harder to understand.

The strange part is that this process often starts with good intentions.

How complexity sneaks in

Most complexity doesn’t start with bad ideas. It starts with good ones that make sense on their own.

A typical pattern looks something like this:

• A user asks for a feature
• The request sounds reasonable, so it gets implemented
• Another user needs a variation of it
• A configuration option is added
• Edge cases appear and require more logic
• Eventually the feature needs documentation just to explain how it works

At that point the system might be powerful, but it’s no longer simple. New users struggle to understand it, and the original clarity of the product starts to disappear.

Many well-known tools didn’t start complex. They slowly accumulated complexity over years of sensible decisions.

The difficult part: saying no

While building my current project, I’ve realized that adding features is rarely the difficult part. The difficult part is deciding not to add something.

Some ideas are obviously bad and easy to reject. The real challenge is when an idea is actually good, but doesn’t quite belong in the product you’re trying to build.

Those are the decisions that shape whether a system stays simple or slowly drifts into complexity.

Right now I’m deliberately avoiding things like:

• complex workflow customization
• estimation systems
• elaborate planning rituals
• too many configuration options

None of these are inherently bad ideas, but they tend to introduce configuration layers that quickly make a system harder to reason about.

Once that kind of complexity enters a product, it rarely leaves.

Still figuring out the line

One thing I’m still learning is where the line actually is. Sometimes a feature sounds perfectly reasonable until you zoom out and realize that it moves the product away from its original purpose.

Saying no to bad ideas is easy.

Saying no to good ideas that don’t fit is much harder.

I’m curious how other builders deal with this.

How do you decide what not to build?

---

For context, I’m currently building a small project management tool and these kinds of decisions come up almost daily.

The thinking behind it:
https://grunna.com

The product (still early beta):
https://ro.grunna.com