Case study, 2026

Drab Launcher: a strategy review of an app built to make a phone boring

Drab is an Android launcher I built to reduce screen time: it puts what you have to do next-to-hand and what you would rather do at arm’s length. After three weeks of building, I reviewed it the way a strategy consultant would: what each feature does to the goal, what the behaviour-change literature says will work, which game-theory rules hold at 11 pm, and what the launcher should become. This page is the review, with the model you can run and the mock screens that came out of it. The targets and the screens use one example user throughout: a student job-hunting from a campus library.

Back to the blog

1. The size of the problem

Survey averages, so that the targets below have a yardstick. Self-reported figures run high; measured pickups run low. The ranges are the point.

A heavy day, illustrative

Modelled on the survey averages above for a student who is online most of the day. Full width is 2.5 hours.

The last two rows are the review’s model in one picture: a launcher with daily typed rituals becomes one of the biggest apps on the phone, and the task apps it is built around barely get opened.

2. Three outcomes instead of one feeling

“Less screen time” is an output. The real outcomes are habits: out of the house by 8, at the library, applications sent. A launcher built around three numbers gets screen time down for free, because the phone is in a bag at the library.

3. Diagnosis: three killers, in order

1. Everything can be undone in ten seconds. An LLM-simulated user critique run during the review named this as the most-cited quit reason. The commitment lock existed and shipped off. Even with it on, changing the clock defeats the shut windows and refills the emergency passes, so the lock has to count elapsed time. The one piece with teeth, a browser whose blocklist is compiled in, was never made the default.
2. Essentials get blocked, so the whole thing gets removed. A deny-by-default gate shuts the transit app the moment it is needed, and fixing the seed list is not enough while every app installed later starts locked. The rule that survives contact with real life: if the phone fails at a bus or a payment, the blocker goes.
3. The model puts the ritual at 15 to 30 minutes of phone use a day. Morning check-in, night check-in, evening wrap-up, judge follow-ups, contract proofs, an idea card, intercept reasons: by the field count, roughly 150 to 300 typed words a day in the evening hours that matter most. A product built to reduce screen time became a daily writing assignment on the phone.

What was genuinely good and had to survive the cut

• The escalating, unconfigurable wait with no repeated excuses.
• Your own words read back, for example: “Last time: ‘just a quick look’, stayed 20 min”.
• The Now row: one task, a red due line, a tick ring, Start 25.
• “Instead” pointing at the next deadline with zero wait for the good choice.
• A permission checklist that says what each permission is for and what breaks without it.
• The honest tone about limits: “friction, not a lock”.

4. What the science says

Evidence grade: 3 meta-analysis, 2 field RCT or large dataset, 1 single small study, 0 anecdote or vendor claim. Where a figure comes from a company’s own summary, the row says so.

5. Game theory: 9 am you against 11 pm you

Treat the day as a game between two players who share a body. The 9 am self values the week; the 11 pm self discounts everything past tonight by a factor β well under 1 (the quasi-hyperbolic model). Every feature is a move by the 9 am self, and the 11 pm self gets the last move. The design question is mechanism design: which rules survive when the player who breaks them is also the referee?

6. The strategic model, and run it yourself

Per feature: effect (minutes a day redirected if active and not bypassed), burden (ritual minutes a day), bypass (seconds to defeat at 11 pm; off-phone means no on-phone switch), essentials risk (weekly chance of blocking a bus, bank or map), evidence (0 to 3, graded as in the table above). Value is minutes saved times the probability the app is still installed on day 30, which falls with essentials risk and with ritual above the user’s tolerance. The coefficients are estimates; the ranking survived every sweep tried.

Marginal value of adding each candidate to the core

Minutes a day, at default urge and tolerance. Three of the top four have zero or near-zero burden. The two features with the most typing are the only ones with negative value.

7. Feature verdicts

What the feature-heavy home got wrong

• Prime slot wasted. The first thing under the date was a fault line or a book quote. Home should answer “what now” in one glance.
• Seven unlabeled dots. No number, no action. Show the week’s four numbers or nothing.
• Three underlines, one hierarchy. A link, a plan prompt and a quote all shared one weight. Nothing was primary.
• The intercept blocked the wrong app. A gate that meets you on the search app you need for a bus time is killer 2 in one screen.
• No breath, no words, no Instead on the intercept. The three things the evidence supports were missing from the screen that exists to deliver them.
• Copy explained the system. “Writing the check-in ends these waits” is a rule, not a reason. The persuasive line is your own sentence from last time.

8. Mock UI: seven screens that aim the phone

Drawn in the product’s own palette (drab on bone). Animations loop so each mechanism can be seen: the breath, the countdown, the tally filling, the walk to the geofence, the deposit ring, the key, the night card typing itself. Scroll sideways.

9. Tricks for the brain, ranked

Ranked by the review’s judgment of evidence, effect and burden. Each names the mechanism it exploits so it can be judged on its own terms.

10. Roadmap and what “done” means

Done is not “built and unit-tested”. Done is: installed for 30 days without an uninstall, no essential app ever blocked, and the three numbers moved against the baseline: feeds under 60 minutes a day, five of seven weekday mornings across the library line by 08:15, 10 applications a day, under 10 minutes a day on the launcher’s own screens.

Process rules the review set

• Seen on a real phone and lived with for a week is the definition of done. Emulator walk-throughs and unit tests are necessary, not sufficient.
• Measure before and after every install, automatically, into a dated folder.
• One batch, then a week of silence. Several batches shipped back to back with no phone check between them is how a feature pile grows.
• Every feature flag is a decision not made. Keep or cut, ship the kept ones on, delete the rest.

Sources

• Pause before the reach: one sec summary and review with study details (PNAS DOI 10.1073/pnas.2213114120)
• Implementation intentions: Frontiers summary of Gollwitzer and Sheeran 2006; Sheeran, Listrom and Gollwitzer, 642 tests
• Plan-making and job search: Abel, Burger, Carranza, Piraino, AEJ Applied 2019
• Commitment contracts: stickK dataset, ICWSM; BMC Public Health 2019 review
• Grayscale: Mobile Media and Communication 2023, Holte, University of Cincinnati (2022 news release, since removed); daily cap: Pieh et al., BMC Medicine 2025
• Temptation bundling: Milkman, Minson, Volpp 2014; fresh start: Dai, Milkman, Riis 2014
• Personal rules: Bénabou and Tirole, JPE 2004; body doubling: arXiv 2509.12153
• Usage averages: Reviews.org 2025 smartphone survey; S&P Global Kagan, Q3 2025; eMarketer via Oberlo; RescueTime 2019