Every feature request is a fork in the road. One path leads to bloated software that tries to do everything. The other leads to focused tools that do one thing exceptionally well. We've seen too many promising products turn into Swiss Army knives—technically capable of many tasks, but clumsy at all of them. I'm taking about you Jira!
The pressure to add features is constant. Users ask for them. Competitors announce them. Investors expect them. But saying no is what separates great software from mediocre software. When you build for everyone, you build for no one.
Take email clients as an example. What started as simple tools for sending and receiving messages have morphed into project management systems, calendar apps, note-taking tools, and social networks. Each feature seemed reasonable in isolation, but together they created complexity that serves no one well.
The Feature Creep Trap
Feature creep happens gradually, then suddenly. It starts with legitimate user requests. "Can you add a simple way to organize these items?" Sure, that's reasonable. Then comes, "Can you add tags to the organization system?" Also reasonable. Then, "Can you add filters for the tags?" Before you know it, your simple tool has become a complex beast that requires a manual to use.
The real trap isn't the features themselves—it's the maintenance burden they create. Every feature needs to be tested, documented, supported, and considered in every future decision. Features interact with each other in unexpected ways. What seems like a 10% addition in functionality often creates a 50% increase in complexity.
The Power of Constraints
Constraints aren't limitations—they're design tools. When you can't add features, you have to make existing features better. When you can't solve a problem with more options, you have to solve it with better design.
Twitter's original 140-character limit wasn't a technical constraint—it was a design choice that forced clarity and brevity. Instagram's focus on square photos wasn't about storage—it was about creating a consistent, beautiful feed. These constraints didn't limit these platforms; they defined them.
Our Approach
We've learned to love saying no. Not because we don't care about user requests, but because we care about the overall experience more than individual features. Every feature we don't build is a feature we don't have to maintain, document, or explain.
Instead of asking "Can we build this?" we ask "Should we build this?" Does this feature align with our core purpose? Will it make the software better for most users, or just satisfy a vocal minority? Does it solve a real problem, or just add another option?
Sometimes the answer is yes. Often, it's no. And that's exactly how it should be.
Simple is Hard
Building simple software is harder than building complex software. Complex software can accommodate every edge case and user request. Simple software has to make hard choices about what to include and what to leave out.
It's easier to add a preference setting than to pick the right default. It's easier to add another field than to question whether the field is necessary. It's easier to build a feature than to convince someone they don't need it.
But the best software makes these hard choices for you. It picks good defaults, eliminates unnecessary options, and focuses on doing fewer things exceptionally well. That's the software we're building, and that's the software we believe the world needs more of.