One Measurable Promise: What Umber Taught Me About Claims That Survive Scrutiny

Umber is a sleep-noise app for Android: you drag one dot around a dark circle to blend pink, brown, and white noise, and it plays until morning. The market for these is crowded, so the product needed one sentence that mattered. Here's the one I chose: 8 hours of playback uses under 3% of your battery.

Instead of "beautifully designed" or "loved by thousands," the pitch is a number about the thing a sleep app's user fears: waking up to a dead phone.

Pick the claim first, then engineer backwards

That sentence dictated the entire architecture. The normal way to play audio streams it continuously, waking the processor about 100 times a second: millions of tiny wake-ups over a night, each sipping battery. Umber instead does all its work up front: it synthesizes one 43-second loop with no audible seam, hands the buffer to the phone's audio hardware, and then does literally nothing for the rest of the night. The hardware loops; the software sleeps; the battery survives.

The audio is beside the point. What matters is the direction of travel: the promise came first, and the engineering was chosen to make the promise true. Most software works the other way: build what's convenient, then let marketing find adjectives for it. Adjectives don't survive contact with a skeptical customer. Numbers do, if the engineering is real.

What this looks like in business software

Every system your customers or employees touch has one measurable promise hiding in it, usually unstated:

• A customer portal: any order's status in under 5 seconds, no phone call.
• A quoting tool: a finished quote in 15 minutes, not 2 days.
• An automation: the Monday report exists by 7 a.m., every Monday, without a human.
• A field app: works with zero bars, syncs when signal returns.

When a project defines its one number early, everything downstream gets easier: scope disputes resolve against the promise, testing has a target, and launch has a pass/fail. When a project has no number, it has no finish line; it just has a budget that runs out. So one of my first questions in any discovery conversation is a version of: what's the sentence with a number in it that would make this project obviously worth it?

Claims need receipts

A claim you can't check is marketing; a claim you can check is a contract. Umber's number is verifiable by anyone with a phone and a night's sleep; battery stats don't lie. The app also removes every asterisk that would soften the promise: no ads, no account, no network permission at all, so nothing runs behind your back to burn the budget the architecture saved.

Demand the same from software you commission. When a developer, me included, makes a performance claim, the follow-up is "how would we measure that after launch?" If the answer is a shrug, the claim was decoration. (It's the same reason I put my own products on this site instead of logos and adjectives: shipped things are checkable.)

Products get sharper when they promise less and prove it; so does client work. If your next project doesn't have its number yet, finding it together is a great first meeting.