purpose
This site would rather help you build a small tool than sell you one.
Convivial tools
Ivan Illich drew a distinction in Tools for Conviviality (1973) between tools that stay subordinate to their user's purposes and tools that begin to determine what the user is allowed to want. The usual reading of him is about scale — small and handmade against large and industrial. That is not the test.
The test is authorship of the goal. A tool that lets you say what you are trying to do and then helps you do it is convivial. A tool that decides for you what you should be trying to do has taken something, even if it picked a goal you would have chosen.
Most products in this market pick the goal. Usually "less screen time", sometimes "streaks", occasionally "focus" as a scored quantity. Those are not obviously wrong goals, but they were not yours, and a tool built around them keeps steering you toward them after your own reason for installing it has changed.
Tools made by the people who use them
There is a position, put to this research directly, that tools of this kind should be built by the people who actually use them. Not as a preference for hobbyism, and not because small-and-independent is a virtue in itself.
A tool that constrains your own behaviour has to encode a judgement about which behaviour, when, and how hard to undo. Those judgements are specific to a person's life in a way a product manager cannot see and a market cannot aggregate. Someone reaching for their phone at 11pm knows things about their own situation that no amount of research on cohorts recovers. The further the author sits from the user, the more the tool has to guess — and the guesses become defaults, and the defaults become what the tool is for.
Which is Illich's problem by a different route. When the author is distant, the goal gets specified for you. When you are the author, it does not.
The paternalism problem dissolves. The hardest question here is whether a tool should embody a judgement about what is good for you. One side says it must, because a fully configurable tool hands the problem back to the person who could not solve it. The other says imposing the designer's judgement is the very mechanism the person is trying to escape.
For a tool you built, the question does not arise in that form. The rule is yours, and the judgement in it is your own — which answers the paternalism problem rather than working around it.
One caution. The self who writes the rule on a calm Sunday morning and the self who meets it at 11pm on a Tuesday are not the same person. That is not a flaw — it is the mechanism. Let the calm self author the rule and the tired self encounter it.
Why a market makes this harder than it looks
This is a category where the ordinary incentives of a product business sit awkwardly against what the product is for.
A tool that succeeded completely would make itself unnecessary, which is a strange thing to build a subscription on. The mechanism most likely to leave you able to manage without the tool — actually building the capacity — is the least tested and the most claimed. Nothing about a recurring revenue line rewards getting there.
The pressures are not sinister and mostly do not need to be:
- Retention is measured, capability is not. A tool you open every day looks healthier in a dashboard than one that made itself redundant in six weeks.
- Engagement mechanics are close to hand. Streaks, scores and notifications are easy to ship, and they are the same techniques the thing you are escaping uses. One maker in this research tested a streak feature against its own outcomes and declined to ship it, which shows both that the test is possible and that it is rarely run.
- A general-purpose product sells to more people than one built for a specific problem. The four problems this site asks about want different responses, and a product addressed to all of them is addressed to none of them precisely.
- Configuration is a cost centre. The honest answer for many people is a setting they already have, which no company has a reason to mention.
None of that makes the commercial tools bad, and this site recommends plenty of them. Several are made by people who have declined the obvious moves and said so on the record. But the market's shape is not neutral, and anyone who can step outside it has an option worth knowing about.
What this site does
It names which of four distinct problems you appear to have, and which class of intervention is aimed at it. The class is the durable part: products change their defaults, get acquired and add a subscription, and the mechanism does not.
Then it offers two routes, and ranks neither above the other:
- Existing tools, with what the evidence supports, what it does not, the price band, and the structural facts about who is behind them. For many people a maintained product is the right answer — somebody else carries the audit and update burden, and that is a real service.
- Things you build or set up yourself, with instructions and, where code is involved, a prompt you hand to a coding agent. A filter rule, a scheduled script, a hosts entry, a drawer in another room.
The second route is newly practical. Writing a small browser extension used to be a project; with a coding agent it is an evening, and what you end up with does one thing, is short enough to read, and belongs to you.
The frameworks are the point, not the code. A prompt this site generates carries the research context, your own answers in prose, and security rules the model is told override anything you ask for afterwards: no network access, no invasive permissions, no dependencies, and a working uninstall shipped alongside the install.
Rule one — no network permission — forecloses the problem structurally rather than promising against it. A browser extension that declares no network permission cannot send your browsing anywhere, whatever bugs it contains, and you can verify that yourself by reading one short file. No privacy policy is that strong.
It is the same test this site applies to the commercial tools. Asking a company what it permits itself to do, and asking whether a tool you built is even capable of doing it, are different kinds of question with different kinds of answer.
A model will write you code that looks confident and is sometimes wrong. Read the prompt before you paste it, read what comes back, and test the uninstall before you rely on the tool. The frameworks reduce that risk; they do not remove it.
Why your phone is the exception
Everything above applies to a computer. On a phone, one half of it does: you cannot safely write code for a phone, but you can absolutely build something yourself out of the features already on it. That distinction matters, and an earlier version of this page collapsed it into "no build path", which was too strong.
There are nineteen no-code recipes in the database for iPhone and Android — a ten-second pause before an app opens, grayscale that arrives when you open the one app that is the problem, a Screen Time passcode somebody else holds, notification summaries, a charger automation. None installs anything. None grants a new permission. One of them is a hand-built version of the best-evidenced mechanism in the whole research.
What follows is why the code route is closed, and it is a limit of the platforms rather than of this project.
iPhone and iPad
Third-party tools reach screen time on iOS through Apple's Screen Time API — the framework family including ManagedSettings, FamilyControls and DeviceActivity. It is a deliberately narrow surface: an app can shield chosen applications and observe activity within tight constraints. It cannot read what is on screen, cannot intervene in another app's interface, and is limited in when it can act.
That narrowness does two things at once. It is a real privacy protection — an API letting third parties watch everything you do would be worse than the problem it solved, and this site's own build rules refuse those permissions for the same reason. It also constrains what a competitor can build on a surface where Apple ships its own product.
The consequence is visible in the results. The iOS products converge on a handful of mechanisms — shield an app, add a pause before it opens, count what you used — because those are the ones the API permits. Interruptive friction has the strongest published evidence behind it, and the version a company can ship on iOS is the version the API allows rather than the version the research would suggest.
The recipes route around some of that, which is worth being precise about. Shortcuts can build a delay and a prompt at the moment an app opens without touching the Screen Time API at all — so the best-evidenced mechanism in the research is available to you by hand even where it is constrained for the companies competing on it. What no arrangement on iOS reaches is element-level exposure reduction inside a native app; for that the route is the web version in Safari with a content blocker, which is why one of the recipes is simply "delete the app, keep the service".
On Apple's motives this site says only what a founder said on the record and what the documentation shows.
Android
Android is more open in principle, and that openness is the problem. The interventions that work need either AccessibilityService — permission to read and act on everything on screen, and the standard vehicle for Android credential theft and overlay fraud — or usage-stats access plus a system overlay, which needs a signed APK, a build toolchain, a keystore and sideloading.
The safe path is harder than the unsafe path. The easy thing to walk someone through is the dangerous one. A page that generated an accessibility-service tool for a non-programmer would be teaching them to grant the most dangerous permission on their device to code neither party has audited, so this site will not do it.
Habituation also outlives the tool. Someone taught that granting accessibility access is normal for a small convenience is more likely to grant it to whatever asks next.
Configuration gets most of the way instead, with no code and no new permission: a minimal launcher, Digital Wellbeing's timers, notification schedules, DNS-level blocking, a separate work profile, grayscale triggered by opening a named app. All of those are in the database with step-by-step instructions, and the diagnostic recommends them where they fit.
every mobile recipe, with its steps · the full write-up, including what each one cannot do
Two of the desktop recipes — DNS-level blocking, and a hosts block on a machine that shares its network — reach your phone anyway, without installing anything on it.