DEV Community

Ethan
Ethan

Posted on

Subtraction as a Feature: What a Tiny Meditation Timer Taught Me About Product Restraint

Disclosure: I work in the OpenNomos ecosystem, which OneZen is a part of.

The first thing I noticed about OneZen wasn't a feature. It was the absence of them.

The settings screen is shorter than the average cookie banner. No account creation. No streak counter. No content library with 400 guided sessions narrated by a celebrity. No "premium unlock" nag on day three. A timer, a breathing rhythm, a handful of natural sounds, and a local record of your sessions. That's the product.

My honest first reaction was: is that enough? I've spent years around SaaS and consumer apps, and my instinct — trained by a decade of roadmap meetings — is that a product this small must be unfinished.

Then I used it for two weeks, and I want to unpack why "small" here is a deliberate design position, not a lack of ambition.

Feature creep has a direction, and it's always inward

Meditation apps are a fascinating category because the job-to-be-done is almost comically simple: help me sit down and be quiet for ten minutes.

Yet look at the market leaders. Subscriptions. Daily streaks. Push notifications that guilt you back ("You haven't meditated in 3 days 😢"). Sleep stories, masterclasses, mood check-ins, social features. Each addition makes sense in isolation — retention teams need retention levers. But stack them up and you get something strange: an app about calm that generates anxiety about using the app.

This isn't a moral failing of any particular team. It's structural:

  • Every feature has an internal advocate. Nobody owns removal.
  • Engagement metrics reward additions. Absence doesn't show up in dashboards.
  • "We added X" is a press release. "We refused to add X" is invisible.

So products accrete. The default trajectory of any successful app is toward more, and it takes an explicit, ongoing decision to hold the line.

What restraint looks like in practice

OneZen's choices read like a list of things a growth team would veto:

  • No account. Your practice records stay on the device. This kills cross-device sync as a feature — a real trade-off — but it also means registration friction is zero and there's no advertising profile being built.
  • No streaks. If you skip a week, the app doesn't know or care. You come back because you want to, not because a number would reset.
  • No content library. A breathing rhythm and ambient sounds. That's the ceiling of complexity. There's nothing to "finish," so there's no backlog guilt.

Here's the part that surprised me: I skip fewer days now than I did with a streak-based app. With streaks, one missed day converted motivation into shame, and shame into churn. With nothing to lose, restarting costs nothing. The absence of a retention mechanic is the retention mechanic.

The uncomfortable question for builders

I keep coming back to this: for most products, the honest version of the roadmap conversation isn't "what should we build next?" It's "what are we adding to avoid admitting the core job is already done?"

There are real limits to the subtraction position. If you want guided courses, OneZen is not for you. If you need multi-device history, local-only records will annoy you. Restraint is a filter, and filters exclude people — that's the price, and it should be stated plainly rather than papered over.

But as a product stance, it's coherent in a way that most "calm tech" marketing isn't. The app's architecture (no account, local data) makes the promise structurally credible. It can't spam you; it doesn't have your email. That's a stronger privacy statement than any policy page.

Takeaways I'm stealing for my own work

  1. Write the not-doing list. For every roadmap item, keep a parallel list of things you've explicitly decided not to build, with reasons. Review it as seriously as the backlog.
  2. Ask what each feature costs the user, not just the team. Streaks cost shame. Accounts cost trust. Libraries cost completion anxiety.
  3. Make constraints architectural. A promise enforced by system design (local-only data) beats a promise enforced by policy.

If you want to see what the subtraction position looks like shipped, OneZen is on the App Store: https://apps.apple.com/cn/app/id6780318004 — the whole tour takes about ninety seconds, which is sort of the point.

Would this approach survive contact with a venture-scale growth target? Probably not. That tension — between products that respect finished-ness and business models that can't afford it — is the more interesting conversation, and I don't think our industry has an answer yet.

Top comments (0)