PRODUCT STRATEGY · SPEC-DRIVEN DESIGN
SayWhen
A scheduling assistant that books what you ask and stays silent until your week drifts from how you meant to spend it. Designed and specified end to end, with every decision framed, argued, and written down.
00 — At a glance
One line.
A calendar with a point of view about your time, and the restraint to speak only when you drift from your own stated budget.
What this page proves.
Not that a thing shipped. That a hard product was reasoned all the way down: a real problem, a narrow wedge, and five load-bearing decisions each carried from question to defended answer, then handed to a build as a spec rather than a wish.
01 — The Problem
The gap you only see too late.
People who live by their calendar do not just want events that avoid collisions. They want the week they actually lived to match the week they meant to live. Intention and reality drift apart quietly, and the gap only becomes visible at the end of the day, in a private reckoning between what you set out to do and what you actually did.
Why the reckoning changes nothing.
That end-of-day gap produces guilt, a small hit to self-trust, and a resolution to try harder next week that rarely changes behavior. The feedback arrives after the moment it could have mattered. You cannot rebook a day that is already gone.
Why existing tools miss it.
Today the options split two ways, and both miss the moment. Auto-defrag tools take the calendar over and rearrange it for you, which removes agency instead of building self-trust. Analytics tools hand back a time-spent dashboard you have to go fetch and interpret later, disconnected from the moment you could still act. And every tool that asks for upkeep loses the user the first time they fall off, because coming back after a lapse feels heavier than the drift itself.
Typeset · problem statement, from the discovery doc
"Existing tools either auto-defragment the calendar, removing agency, or hand back time-analytics dashboards you have to go fetch after the fact. The desperate user feels this daily, most acutely in the evening, and has abandoned every tool that tried to help because the cost of coming back after falling off felt heavier than the drift itself."
02 — The Wedge
One user, not everyone busy.
The wedge is deliberately narrow: an individual professional who manages their own calendar, has no assistant, and cares about the shape of the week (deep work versus meetings versus personal versus a side project), not just collision-free events. Not teams. Not admins. Not everyone who is busy. Widening the user was the first thing refused, because the whole design depends on the calendar belonging to one person with one intention.
Same interaction, aimed somewhere else.
The 2026 wave of conversational scheduling points plain-language booking at coordination: negotiating your calendar against other people's, the corporate assistant problem. SayWhen borrows that interaction backbone and aims it at a private target instead: the gap between how you meant to spend your own week and how you did. The interaction is familiar. The problem it serves is not the one the category is chasing.
The narrowest useful version.
You set a rough weekly budget across a handful of facets once. Then you book real events by telling SayWhen in plain language. When a booking would push a facet past its budget, it says so inline and offers a one-tap correction. When it would not, it just books and gets out of the way. What you walk away with is a booked event and, only when you were about to drift, one honest and actionable line at the moment you could still change course.
03 — Attribution
The decision: infer facets, never make the user tag.
For the budget to mean anything, the system has to know which facet an event belongs to. The obvious answer is to make the user tag events. That answer was rejected on sight, because manual tagging is exactly the upkeep that loses the user. So attribution is inferred from the real calendar and never asked for. This is the decision the rest of the product leans on, and also the riskiest, because inference is wrong sometimes and the design has to stay honest about that.
Cold start, so the desk is never blank.
On connect, SayWhen reads calendar history and pre-attributes, seeding the mapping from how your people and standing meetings already cluster. The console lights up populated, not empty, and no action is asked for during the read.
Warmup, so it never sounds confident before it is.
Attribution confidence is a visible, per-facet state. Until a facet's attribution crosses a bar, nudges for that facet are withheld or softened. The system does not get to deliver a sharp judgment on a facet it is still learning. Warmup is legible on the surface as "still learning this one," distinct from the mature "you're fine" silence.
The self-retiring receipt.
Early bookings carry a soft, tappable line showing where the event landed ("· 30 min → Deep work") so you can correct a misattribution in one tap. A correction teaches a mapping keyed to that entity. As confidence grows, the receipts fade to silence on their own. They are training wheels that know when to come off.
Typeset · the two governing rules, reworded as page copy
BR-9. Nudges are withheld or softened until attribution is confident. Warmup is a visible, per-facet state, never a hidden one.
BR-10. Attribution is inferred, never tagged, and always correctable through a receipt that retires itself once it is trusted.
04 — Weekly Envelopes
The decision: fixed weekly envelopes, not rolling windows or daily quotas.
Budget needs a measurement window, and the window shapes the whole feel of the product. Rolling windows are muddy and never let you feel current. Daily quotas nag. The call was a fixed calendar week, Monday to Sunday: the booking is judged against the week it actually lands in, every warning names that concrete week, Monday resets the envelopes clean, and recurring events pre-debit the future weeks they will occupy. No carryover, no debt.
Budget is a baseline, not a contract.
The budget is a line you set for yourself, not a limit the system enforces. Every drift flag keeps "Book anyway" one tap away. In-flow, the only budget move is accepting the exception. There is no in-flow rebalancing and no zero-sum trading between facets, because forcing a rebalance at the booking moment turns a calm heads-up into a negotiation.
Overflow is shown honestly, never punished.
When a facet runs past its mark, the standing shows past-cap in a calm amber, never red, because red is reserved for a write failure and over-budget is not a failure, it is a fact about the named week. Monday's reset restores the baseline. There are no streaks, no catch-up view, no guilt recap. The one hard color rule: the over-budget signal is never carried by color alone.
Repeated overruns become a question, out of flow.
The system does not nag per event. It lets exceptions accumulate. When a facet runs over several weeks straight, SayWhen raises one gentle question outside any booking moment: is this higher number just what your weeks look like now? One tap raises the line, one tap keeps it. Observed behavior is allowed to move a budget, but only through a door that is not the booking flow.
Typeset · the exception, verbatim in spirit
In-flow, the console never rebalances your week for you. It states the fact and leaves the choice: "Book anyway." The budget bends because you decided it should, not because the software negotiated you into it.
05 — Facet Sovereignty
The decision: intention is sovereign.
A facet exists because the user says their time should go there, not because the system can detect it. The product must not refuse solo, transient, or hard-to-see facets. The gym, focus time, a one-off project all count, because the person says they count. That principle draws a clear line and accepts a clear cost, stated plainly rather than hidden.
Setup is a conversation in three beats.
Budget is set once, in three light beats: mirror, gap, hours. The mirror proposes facets read from your real calendar, each with tap-to-claim chips harvested from your own recurring event titles, a word bank rather than a tagging chore. The gap asks the one question that history cannot answer.
Typeset · the question that earns the install
"What is missing that you want to protect time for?"
This beat names the starved or absent facets, the gym, the side project, that have no calendar history to mine. They are the reason anyone installs the app. The console is only allowed to be quiet after this conversation has happened.
No cap, warmup as the governor.
There is no hard limit on the number of facets. An arbitrary cap would contradict the sovereignty principle. Warmup acts as the emergent governor instead: facets you barely use never earn a confident voice, so the system self-limits without a rule that tells the user their intentions are too many.
The accepted failure mode.
The cost of sovereignty is stated out loud: dead facets linger until the user deletes them, and a facet you flagged as protected but then starved for weeks will not be nagged in flow, because the in-flow nudge defends ceilings, not floors. The design's answer to the second case is an out-of-flow question that reads as permission, not reproach: keep protecting this, or ease the line so it can be honest? If the time you said mattered stayed empty for weeks, letting the budget become truthful is a dignified outcome, never a scold.
06 — How AI Fit
Where AI actually sat in this.
Two places, named honestly. The interface was designed in Claude Design, which produced the visual system and the full thirty-six-screen Quiet Console set every figure on this page is drawn from. The thinking was run as a documented, spec-driven pipeline: discovery, requirements, a UX approach and spec, and a tech handoff, each one a real artifact rather than a conversation that evaporated. Twelve business rules, a full state-coverage trace, and an accessibility floor were written down and carried forward so the build brief lifted the chosen UX instead of regenerating it.
What the method is.
Decisions were resolved one at a time and logged with the reasoning attached, so every call on this page can be traced to the document where it was argued. That is the differentiator this whole site is claiming, and this project is where it is shown rather than asserted. The planned in-product model was Claude Sonnet 4.6, handling the plain-language booking parse with structured output and a strict calendar tool, with the drift check running in the same request so the judgment lands inside the booking moment.
What AI did not do.
It did not make the decisions in sections 02 through 05. The wedge, the attribution stance, the weekly envelope, and facet sovereignty were human calls, and the value of the artifacts is that you can see them being made. And it did not build a shipped product. This project is the design and the spec, in full. The build is a separate story on a separate page.
Typeset · the pipeline, as it actually ran
01 discovery · 02 requirements · 03 UX approach and spec · 04 tech and handoff
Each phase an artifact. Each decision logged with its reasoning. The interface built in Claude Design against that trail, not ahead of it.
07 — Status and What's Next
Status, stated plainly.
Designed and specified end to end. The design track was the deliverable that mattered here, and it is complete: the flows, the states including the hard silent one, the business rules, and the handoff all exist. The build was scoped as a parallel stretch and then shelved on purpose, to put the same effort into a related app in the same lane. That is a focus decision, not a stall, and the honest version of it belongs on the page rather than a "shipped" badge that would not be true.
The question left open.
One question is parked rather than answered: should the system ever advocate for a facet that is being starved? Today the in-flow nudge defends ceilings only, it speaks when you go over, never when you quietly abandon something you said mattered. The protected-shortfall suggestion is the design-only exploration of the other side of that line, and whether a scheduling assistant should push you toward the time you protected, not just warn you off the time you overspent, is a real open question I was comfortable leaving open.
On what this is.
It is possible this ends up a personal tool rather than a market product. That was true from the start and it is not a failure of the exercise. The point was to take a problem I feel daily and reason it all the way to a buildable spec, in the open, with the judgment visible. That part is done.
