Stop Shipping Everything: Why My Best Products Have Less, Not More

Last year, I shipped a feature that took three weeks to build. It handled some edge case that maybe 2% of users would ever hit. It was technically elegant, well-tested, and completely unnecessary. Two months later, I deleted it. Nobody complained. That's when I realized I'd been building like someone afraid of making the wrong choice—so I made every choice instead.

I think a lot of developers do this. We optimize for completeness rather than clarity. We assume more features equal better products. We ship the feature salad and hope something sticks. But after working on several projects that actually achieved some stickiness, I've come to believe the opposite: the products people actually use are the ones that know exactly what they're not doing.

The Feature Trap is Real

Here's what happens in most projects I've seen: someone opens a ticket system and suddenly there are fifty things to build. Payment flows, error handling, edge cases, "nice-to-have" features, integrations that nobody asked for. The backlog becomes this gravitational pull that drags the entire product away from what actually matters.

The original article calls this the "feature-first" approach, and I've lived it. You convince yourself that just one more thing will make it perfect. Then another thing. Then you're months in and the core experience is buried under a mountain of stuff that made sense in meetings but doesn't matter in reality.

The worst part? This approach doesn't make the product better—it makes it fragile. Every additional feature is another place something can break, another path to test, another reason users feel confused.

What "Bedrock" Actually Means for Developers

The article uses the term "bedrock" to describe the core value your product delivers. For a banking app, that's checking your balance and paying a bill—the daily stuff, not the occasional signup flow.

For me, bedrock is the difference between "shipping a product" and "building something people trust enough to return to." It's the features users access every week, not the ones they use once and forget about.

This is harder to identify than it sounds. You need to actually watch people use your thing. Not in a controlled user testing environment, but in production. Where they're rushing, where they make mistakes, where they abandon the flow entirely.

When I built a dashboard for a previous client, I thought the "advanced reporting" was bedrock. Turns out, nobody cared. They needed one specific view they could glance at in three seconds. Once I stopped fighting that and leaned into it, everything else became noise I could cut.

My Take: You Need Permission to Say No

Here's where I disagree with some interpretations of this approach. The article mentions needing "guts" to stick to your vision, which is true, but I'd go further: you need organizational buy-in. A single developer saying "no, we're not building that" will lose every time to five stakeholders saying "yes, but we need it."

The real work isn't the engineering—it's the conversation. You have to help your team understand that saying no to 10 things means saying yes to doing 1 thing extremely well. That's a business decision, not a technical one.

I've also learned that bedrock isn't static. It evolves. The feature you cut in month one might become crucial in month six. The key is iterating ruthlessly, measuring constantly, and being willing to admit you were wrong.

What This Looks Like in Practice

For a recent project, we started with a ruthless scope. We identified three core user journeys. Everything else was explicitly marked "not in v1." We shipped in six weeks instead of six months.

Then we measured. We tracked which features people used (spoiler: not the ones we thought). We cut two of them immediately. We expanded one by 40% because it was the bottleneck.

The result? A product that actually solved the problem, not a product that tried to solve every problem.

The Question I'm Still Wrestling With

How do you know if you're solving the right problem at the right depth before you launch? I still don't have a clean answer. You can do research. You can talk to users. But until real people use it under real pressure, you're always guessing.

What's your experience? Have you had to cut features you loved because they didn't matter? Or have you shipped something minimal and watched it fail because you were actually missing something crucial?

Source: This post was inspired by "From Beta to Bedrock: Build Products that Stick." by A List Apart. Read the original article