There's a peculiar paradox in building things: the simpler something appears, the harder it usually was to make. This seems counterintuitive. Shouldn't simple things be... simple to create?

I've been thinking about this a lot lately. Every time I sit down to build something "simple," I end up in a rabbit hole of complexity. A basic to-do app becomes a meditation on state management. A landing page spirals into typography hell. A "quick script" evolves into a distributed system.

The Complexity Iceberg

Simple things are hard because simplicity is the result of ruthless editing. It's not the absence of complexity—it's complexity that's been carefully hidden, resolved, or eliminated entirely.

Think of an iceberg. The visible part—the simple interface, the clean design, the obvious feature—is just 10% of the work. Below the waterline sits the other 90%: edge cases handled, decisions made, alternatives rejected, and compromises reached.

"I would have written a shorter letter, but I did not have the time." — Blaise Pascal (maybe)

Pascal's quote captures it perfectly. Brevity takes effort. Simplicity takes even more.

The Three Enemies of Simple

In my experience, simplicity has three main enemies:

Feature creep: The temptation to add "just one more thing" because it might be useful someday.
Premature abstraction: Building for flexibility you don't need yet, adding layers that obscure rather than clarify.
Fear of commitment: Refusing to make decisions, keeping options open, and ending up with a mess of configurable complexity.

Each of these feels productive in the moment. Feature creep masquerades as thoroughness. Abstraction feels like good engineering. Keeping options open seems prudent. But they all lead to the same place: complicated systems that are hard to use and harder to maintain.

The Discipline of Deletion

The solution is deletion. Not just of code, but of ideas. Of possibilities. Of the fear that you're missing something important.

Every feature you don't build is a feature you don't have to maintain. Every option you don't offer is a decision your users don't have to make. Every line of code you don't write is a line that can't have bugs.

This is harder than it sounds. We're wired to add, not subtract. Removing something feels like loss, even when that something was making things worse.

Simple Is Not Easy

There's a distinction worth making here: simple is not the same as easy.

Easy means low effort
Simple means low complexity

These often point in opposite directions. The easy path is to add another option, another feature, another layer of abstraction. The simple path requires the hard work of understanding what's essential and having the courage to cut everything else.

Simple is a destination you reach through difficulty, not a shortcut that avoids it.

Practicing Simplicity

How do you get better at making simple things? A few approaches I've found helpful:

Start with constraints. Limit your tools, your time, your scope. Constraints force creativity and prevent sprawl.
Ship early. The sooner you put something in front of users, the sooner you learn what's actually necessary.
Revisit and remove. Schedule time specifically for deletion. What can you take away without losing value?
Study simple things. Use products that feel effortless and try to understand how they got there.

Simplicity is a skill. Like any skill, it improves with practice and intention.

The Payoff

Why bother with all this? Because simple things are better. They're easier to use, easier to understand, easier to maintain, and easier to love. They respect the user's time and attention. They solve the problem without creating new ones.

And perhaps most importantly: simple things last. Complexity is fragile. Simplicity is resilient.

So next time you're building something and it feels too hard for how simple the result should be—take heart. That difficulty is the price of simplicity. And it's worth paying.