Most productivity tools store an answer once you have decided it. DecideLess is built to remove the deciding.
It turns an ordinary-language request into a structured proposal — a task, a choice already made, or a long-term plan — and changes nothing until you confirm it. Every applied change can be undone. The goal is not a faster to-do list. It is a day that asks fewer times.
One sentence in. A proposal you can accept or reject.
The rest of this case study argues for a particular interaction. This is that interaction, running in your browser — no sign-up, no download. Tap one of the suggested prompts inside the phone and watch what comes back: a draft you confirm, not a change already made.
A to-do list helps you remember a responsibility. It does not judge whether now is worth it, decide what comes first, or hold the rhythm when life changes.
Defined the product and its boundaries, designed a confirmable AI planning system, and directed the build across 18 workstreams and 159 records to a signed native release in four weeks.
A private native build, V2.1.21, in which every AI write is inspectable and reversible, and four failure modes were traced to root cause.
The morning I did everything right and still did not go
For months I wanted to buy clothes. The intention never went away and the trip never happened.
One morning I did everything right. I got up early, showered, got ready, and stood at the door — and then reconsidered. Would I actually find anything today? If not, I would rather have the afternoon back. I stayed home. Weeks later the season turned and I had nothing suitable to wear.
Nothing had been forgotten. I had remembered, prepared, and still lost to a decision made at the doorway. That is why DecideLess is not a reminder app.
Groceries failed in a different shape and landed in the same place, and so did housework. Every small responsibility quietly asks for four things: remember it exists, judge whether now is worth it, decide what comes first, and hold the rhythm as life changes. A to-do list only helps with the first. The other three are decisions — and they cost the most at exactly the moment attention is already spent.
I described the pattern to friends and colleagues in ordinary conversation, and it came back recognizably: different errands, the same stall between intending and acting. Informal corroboration, not research — enough to justify building something testable, not enough to claim a market.
Deciding costs more than remembering
My own stalled errands were a signal, not a finding. I needed to know how much everyday deciding people actually do, whether that load has a shape I could design against, and how far the evidence for the effect really goes.
a day spent deciding which to-do item to tackle first, among UK adults who already keep a list. The list had solved remembering. What was left was deciding.
The most useful result was not the total. In a UK study of 2,000 adults, people who already keep a to-do list still spend an average of 27 minutes deciding which item to tackle first.
The load also has a documented structure. A 2019 American Sociological Review study of 35 couples describes household cognitive labor in four phases: anticipate, identify, decide, monitor. I had already written down four steps from my own experience, and they line up almost exactly. That changed my scope — a tool that carries only the first phase is helping with the part that was already easiest to hand off.
I also decided what not to claim. The widely repeated figure of 35,000 decisions a day has no primary source I could find, and decision fatigue as a construct is contested. So the product targets the frequency of low-value decisions — something a user can feel and I can design against — rather than a depletion effect I cannot demonstrate.
Opportunity identified
Each existing category is strong at its own job, and each leaves the same thing open.
Separate doing from deciding
Reduce repeated, low-value decisions and future-memory burden without asking people to maintain a detailed database of their lives?
Traditional to-do lists make almost everything look like work to complete. DecideLess uses two content models, because they remove different kinds of mental effort.
This was the core product decision, not a feature choice. Without the Decision model, DecideLess would mainly be an AI-powered calendar. With it, the value proposition became visible in the interface, and the product owned one commercially meaningful wedge instead of competing on breadth.
AI was an implementation choice, not the strategy. The strategy was to remove repeated mental work; the AI layer had to turn ambiguous language into predictable product behavior as one governed component — not the database, the source of truth, or the final authority.
AI is allowed to be useful before it is allowed to be irreversible. The confirmation step is not friction to remove; it is what makes a powerful system understandable and recoverable.
What I deliberately did not build
- Do not own meaningful decisions. Build for repeated, low-value choices; do not position AI as the owner of consequential personal ones.
- Do not configure before conversing. Users should not have to reconstruct their wardrobe, pantry, home, and routines during onboarding.
- Do not hide the automation. Do not optimize for minimum taps at the cost of invisible changes.
- Do not become a work suite. This is a life-planning assistant, not general project management.
From one sentence to a confirmed plan
You type or speak a request in English, Chinese, or mixed speech; the assistant reads the selected date, existing items, visible occurrences, and recent context; it returns structured create, update, move, delete or skip operations labelled in human language rather than database identifiers; nothing changes until you approve; then the app moves to the affected date, shows the result in place, and offers Undo.
Two requests a calendar cannot answer
In both, the user supplies an intention and the product supplies the part that was actually expensive.
Asked to plan a trip to watch the next meteor shower from a stated city, the assistant does not hand the question back. It looks up when that shower next peaks and whether it is visible from that location, then returns a dated proposal to confirm.
A user says a box of cat litter lasts about five weeks, delivery takes three days, and the last box was bought on 20 July. No date is given, because the user does not have one — what they have is a rate and a constraint. The product derives the series, each occurrence placed three days before the supply is due to run out.
The second one is the more valuable, because it does not end. A one-off lookup removes one decision. A derived cycle removes the same decision every five weeks for as long as the cat is around — and it self-corrects: each occurrence re-anchors on the date the user actually completed the last one, not the date the plan predicted. Order two days late and the whole series moves with you.
The expensive part of “I need to keep the cat in litter” was never writing it down. It was the looking up, the working out, and the deciding that sat between wanting it and scheduling it.
Four weeks, four gates, and no engineer
The whole sequence ran inside four weeks in July 2026: web/PWA validation, native rebuild, hardening, and a signed release build. That compression is the argument, not a footnote. When AI collapses the cost of writing software, engineering capacity stops being the binding constraint — and the scarce resources become deciding what deserves to exist, and knowing when a stage is genuinely finished.
Every line of DecideLess was written by AI. The problem selection, product decisions, interaction rules, QA, and release judgment were mine. I ran the work through one ticket and decision ledger — 18 workstreams, 159 records, 111 closed — with decision gates before dates, and P0 product logic and data safety before P1 polish.
A cost decision that inverted the product promise
The mobile backend was configured with a smaller model and a reduced token budget; the web build had used a larger one. Asked to plan a week of lunches, the assistant began interrogating me — which dishes, the same every day? A product whose entire claim is that it decides so the user does not have to was asking more questions than a form would.
Comparing the two implementations found two causes rather than one. The model was smaller, and with incomplete information a small model asks instead of deciding. But the mobile prompt had also lost the web version's instruction to call the tool directly — a tool call is only a proposal the user confirms — while keeping its negative counterpart, never claim a change has already happened. It forbade overclaiming without authorizing action.
Then it compounded. Because the assistant kept asking, unconfirmed requests accumulated in the history and were re-proposed on the next turn, arriving separately as an apparently unrelated defect: cancelled work coming back to life. One configuration choice produced two distinct user-visible failures.
I now treat model selection and token budget as product-quality decisions rather than infrastructure settings. A cheaper model is tested against the product promise, not against whether the response parses.
What the current build delivers, and what it does not
DecideLess exists as two working implementations. The web/PWA version proved the product model and the AI interaction. The native V2.1.21 build carries that model into its intended daily context with voice, local notifications, mobile authentication, and a hardened API.
Verified. Native typecheck, schedule verification, and Expo SDK 54 dependency checks pass. The hardened backend build and its security regression suite pass. Grounded scheduling and derived consumable cycles were both exercised end to end on V2.1.21. A signed release build exists.
Not yet proven. The app has not been publicly released, and no one other than me has used it long enough to claim reduced decision effort at any scale. Every figure in this case study describes delivery, verification, and failure-analysis work. None of them are user outcomes.
Next is a two-week pilot with 5–8 people, measured on four questions: do people understand the difference between a Task and a Decision without being told; do they accept, correct, or dismiss what the assistant proposes, and does that change after it gets something wrong once; do notifications arrive when the schedule says they will; and does repeated planning effort actually fall — before any investment in multi-user, distribution, or personalization.
From private build to public release
DecideLess is a finished product build today, used by one person and released to no one. The plan between those two states is ordered by what each step unblocks, not by what is easiest to build next.
- 01 A public static demo — before this case study shipsThe portfolio's durable asset should be a zero-dependency demo rather than the live product. Someone opening the link months from now should not depend on a subscription, an API balance, and a beta hosting product all still being alive.
- 02 Edge rate limiting and a geographic allow-list — before the API is opened past meApplication-level limits still cost a worker invocation and a database write for every rejected attempt, and the login endpoint runs a 600,000-iteration key derivation. The edge is the only layer that can refuse a request before any of that runs.
- 03 Refresh-token replay detection — before the first account that is not mineTokens rotate today, but reusing an old one does not invalidate the session chain. The risk is low with a single user and stops being low the moment there is a second.
- 04 A two-week pilot with 5–8 people — the next decision gateReal recurring responsibilities, measured against comprehension, proposal trust, and reminder reliability, paired with a before/after measure of repeated planning effort.
- 05 Multi-user architecture — only if the pilot earns itThe app currently shows a sign-up entry that leads nowhere, because the backend is a single-email allow-list. That reads as a copy problem and is not one: real multi-user means a registration flow, per-user cost accounting, and abuse controls.
Replace the demand for certainty with a system for evidence
My instinct is to ask whether a product can solve the real problem and stay reliable if it succeeds. That instinct produced the trust, security, and failure controls in DecideLess. It is a product-owner strength — and it becomes a constraint if certainty is required before learning is allowed to begin.
Remembering and deciding are different problems; no reminder would have helped me at that doorway. The wedge mattered more than the feature list. Model selection turned out to be a product decision, not an infrastructure setting. And when code gets cheap, deciding what should exist gets expensive.
A product manager does not predict the future. A product manager creates a sequence in which the evidence gets better.
The shift is from “prove it will be valuable before I start” to “make validation part of product development.”
DecideLess is a private build. The figures in this case study describe delivery, verification, and failure-analysis work. They are not user outcomes, and none of them should be read as evidence that the product reduces decision effort for anyone but me.
