MinutePad

Most to-do apps for everyday errands are too heavy: you create projects, add tags, drag things on a timeline, and writing one thing down already takes more than a minute. I wanted the opposite extreme. Add, schedule, complete, delete, each within a minute. Time can be unset, a slot (morning, afternoon, evening) or exact to the minute. Anything unfinished shows up tomorrow by itself.

The second problem was mine. This is a solo developer's first subscription app, aimed at Taiwan, Hong Kong, mainland China, English and Japanese markets at the same time. Scope, pricing line, privacy promises: every decision needed a recorded reason, or three months later I would not be able to explain it even to myself.

The primary users are people who need to jot a task down fast: office workers, caregivers, anyone juggling five small things. The moments are fragments of time, walking, waiting for a bus, two minutes before a meeting. So input has to be quick (text, or a photo through on-device OCR), reminders have to be precise (on time, or 5, 10, 15 or 30 minutes early), and the home-screen widget has to let you check things off directly.

The second user is the AI I build with. Claude Code starts every session from zero and needs a stable statement of what this product is and is not. CLAUDE.md is the product requirements doc written for it.

• Solo developer: no backend team, so v1.0 cannot depend on my own server; data stays on the device, with no account and no third-party SDK.
• Subscription: the free tier has to be good enough to install, Pro has to be worth buying today, and everyday notes must never be locked away.
• Five markets: copy and OCR languages for Traditional and Simplified Chinese, English and Japanese; a palette that does not flatter only one place.
• AI cost and safety: scheduling calls Azure OpenAI directly, so key protection has to be solved before launch.
• Documentation debt: the dev log and the user-survey file are empty, so back-filled decisions could only be dated from file timestamps, and that had to be stated honestly.

Four mechanisms carry the product: three time granularities (none, slot, exact); carry-over (copy to today and soft-delete the original, so the calendar still shows yesterday); an interactive widget (an AppIntent writes check-offs into an App Group queue that the app applies on foreground, so two processes never write the same store); and the AI scheduler (pick up to five tasks, the AI proposes times around the current clock, occupied and blocked slots, and every suggestion needs the user's confirmation).

The three biggest trade-offs. First, AI moved from Phase 4 into v1.0, but its scope shrank from Eisenhower classification to 'fit today's unscheduled tasks into the day'. Second, the free/Pro line was drawn at 'everyday notes free, effortful automation paid': free users get three AI runs a day for today and tomorrow; Pro adds unlimited runs, blocked slots, recurring tasks and tasks beyond tomorrow. Third, v1.0 ships without iCloud sync. The planned CloudKit container never left its stop-gap, and rather than discover schema conflicts after launch I wrote the simplest privacy story: everything stays local.

I treat CLAUDE.md as the AI's PRD. It holds positioning, the feature list, Pro pricing, a file index, the launch checklist and, most importantly, a 'not in this project' list: CBT-style procrastination nudges and habit analysis belong to a different product. That section did more work than any feature description. The seeds of a CBT nudge had appeared in the code; once the boundary was written down the AI stayed inside it and the leftover code was marked for removal.

The decision log is the second thread. Every entry in DECISIONS.md has context, options, the decision and the conditions for changing it, from 'SwiftUI vs Flutter' to today's key handling, 26 in all. It allows reversals: D012 chose XcodeGen, D015 admits Xcode took over the project file and even records 'never run xcodegen'.

The most persuasive moment was the AI getting it wrong and being corrected. The plan said scheduling would go through a relay to protect the key; to get the feature running, Claude wrote the Azure key straight into Swift. My security check before the first git commit caught it. I laid out three options and chose one; Claude moved the key into a git-ignored xcconfig injected through Info.plist, and both configurations were verified with xcodebuild. A boundary holds because of a checkpoint in the process, not because the AI means well.

• v1.0 feature-complete: note CRUD, three time granularities, reminders, OCR (library and camera, on-device), calendar with search, Apple Calendar export, interactive widget, carry-over, recurring tasks, blocked slots, AI scheduler, StoreKit 2 subscriptions.
• Three themes (amber, warm earth, lavender); the widget recolours on switch.
• 26 logged decisions, a root README as documentation map, a CLAUDE.md boundary statement, and a private repo with no keys in it.
• App Store copy drafted in three languages with a privacy policy draft; screenshots produced.
• Status: built, awaiting launch (screenshots, hosted privacy policy, TestFlight, review).

First, actually keep the dev log. Back-filling twelve decisions meant dating them from file timestamps, and only the most recent 'AI corrected by a human' episode has complete evidence. A decision log is valuable when written in the moment, not reconstructed later.

Second, run the security check before the first line of code, not before git init. Had CLAUDE.md already said 'keys come only from xcconfig' when the key was first written, the AI would not have taken that shortcut. A PRD for an AI needs 'how you may not do it' alongside 'what we do not build'.

Third, the privacy policy draft says 'no data is transmitted', yet the AI scheduler sends task text to Azure OpenAI. Copy and code evolved separately and nobody reconciled them. The launch privacy policy has to be rewritten from the code, not from the wish.