The most dangerous phrase in software development is "while we're at it." A client asks for a login page, and suddenly you're building OAuth, social login, two-factor auth, single sign-on, passwordless magic links, and biometric authentication. The login page ships four months late.
Features are liabilities
Every feature has a cost. Not just the time to build it — that's the cheap part. The expensive part is maintaining it forever. Every feature needs tests, documentation, bug fixes, security patches, and compatibility with every other feature. The cost compounds over time.
A product with ten well-built features is better than one with fifty half-baked ones. Users would rather have five things that work perfectly than twenty things that kind of work.
The "would this be nice?" test
When a feature request comes in, I ask one question: "Would this be nice, or is this necessary?" If the answer is "it would be nice," it goes on a list and we revisit it later. If the answer is "users literally can't use the product without this," it gets built.
Most features that seem urgent in a meeting become irrelevant within a week. The ones that keep coming up — the ones that multiple users independently ask for — those are the ones worth building.
Scope creep in practice
I worked on a project where the original spec was a simple dashboard with five charts. By the time the first meeting ended, the spec included real-time updates, data export in four formats, customizable layouts, role-based permissions, email reports, and a mobile app.
We shipped the original five charts. They were good. The client was happy. Six months later, we added export and real-time. The mobile app never happened because nobody actually needed it.
How I manage scope
- Write it down. If a feature isn't in the spec, it doesn't exist. Verbal agreements become misunderstandings.
- Ship in phases. V1 does the core thing. V2 adds the first round of nice-to-haves. V3 is based on actual user feedback, not guesses.
- Say "not yet" instead of "no." Clients hear "no" as "never." "Not yet" means "let's ship the important stuff first and come back to this."
- Estimate the maintenance cost. Before adding a feature, ask: "Am I willing to maintain this for the next three years?" If the answer is no, don't build it.
Less is more
The best products aren't the ones with the most features. They're the ones that do one thing exceptionally well. Google's homepage is a text input. Craigslist hasn't changed in twenty years. They're not missing features — they're focused.
Build less. Build it better. Ship it sooner.