Designing and building a daily brief for an audience of one

The setup

I already had the tools. A digital planner for the month and the week. A handwritten journal, fountain pen and all, for whatever needed to come out. Between them, every morning, a gap: nothing gave me a daily snapshot that said “here’s today, you’re already in it.”

The gap only hurt when things got hard. When work or life got loud, the planner started to feel like one more thing to manage, so I stopped opening it, and I lost the thread of my days. The journal survived those stretches because it asks nothing of me except honesty. I wanted a third thing that lived between structure and freedom. Something just there each morning, not punishing me for yesterday, not demanding I optimize today. A presence tool.

There was a specific constraint underneath it, and naming it changed the whole design. My ADHD does not present as task paralysis. It presents as time anxiety. A single dreaded appointment, even a neutral one at noon, and my brain spends the whole morning counting backward from it. Three hours. Two hours. One. Everything else in the day disappears behind that one clock.

So this was not a productivity app, a habit tracker, or a meditation app. It was a way of saying: before Slack, before email, before the calendar takes over, I see my day and I know its shape. The working title became the whole philosophy. Start the day as a person, not a reaction.

Where I came in

I was every role on this one. The designer, the engineer, and the single user whose patterns the whole thing had to fit. That is the unusual part worth stating plainly: there was no user research to run because I was the user, and no handoff to engineering because I was building it too. The discipline had to come from somewhere else.

It came from process. I refused to start with features. I started with three questions, in order: what do I want to feel when I open this, what is already working that I need to protect, and what do I know I do not want. Feeling first, then philosophy, then constraints, and only then features. That sequence is exactly how I approach product design professionally. The difference here was speed, because the feedback loop was me.

Out of those questions came one governing rule that every feature had to pass. I call it the guilt audit: does this manufacture obligation? Streak counters do. “Overdue” labels do. Carrying yesterday’s unfinished tasks into today does. A countdown to an appointment does. The brief does not avoid negativity, it avoids manufactured obligation, which is a narrower and more useful constraint. Designing against that taught me something I have carried back into my day job.

The opposite of delight is not frustration. It is dread. Designing against dread takes a different kind of empathy than designing for delight.

What I built

A daily brief that opens to the shape of one day and nothing more. I built the first version as a live app inside Cowork, Claude’s AI workspace, which meant I could design it and run it in the same place, pulling my real Google Calendar and weather through a live connection instead of standing up OAuth flows and API keys first. That let me spec something Friday night and live with a working version by Saturday morning. The container could wait. The feeling could not.

Shape over countdown is the load-bearing decision, and it came straight from the time-anxiety constraint. The brief never shows a countdown or “in X hours” language. It shows the day as a set of points, none of them the gravitational center. A 9:30 appointment sits on the timeline beside the noon and the 5pm as an equal. It is part of the day, not the whole day. A generic planner would ship countdown timers as a feature. Understanding one person’s anxiety turned that feature into an anti-pattern.

A morning read with a deliberate order. The brief is a short vertical read, and the sequence is the design. Your morning rhythm comes before the calendar on purpose, because the rhythm is my intention and the calendar is the world’s claim on my time. What follows moves from internal to energetic to practical: how today feels, what today’s energy is, then what today actually looks like. Sections that are reference rather than ritual collapse by default, so the daily read stays light and the depth is one tap away.

A voice designed for one person. The grounding thought and the horoscope both speak in what I named the “you-after-coffee” voice: me after the first cup, grounded, lightly coach-like, not the peppy-productivity or clinical-wellness or affirmation-speak registers I ruled out. In v2 I made that voice actually see the day. The reflection is generated with the season, the day’s shape (open, light, full, or packed), and personal context as input, so a quiet late-June Sunday reads differently than a packed Tuesday. I deliberately fed it context for the voice rather than topics to address, so it sounds like someone who already knows I have ADHD instead of telling me to be patient with it. For the same reason I dropped the horoscope API I had planned: generic Virgo content pasted into this voice would read like a newspaper clipping in a handwritten letter, so I generate “the stars today” from the same inputs. The goal was never astrology. It was a morning with a point of view.

Calendars that know whose day it is. The original build pulled only my personal calendars to keep work out. That created a lie: a Monday with a full workday but an empty personal calendar announced itself as “open.” For a tool whose whole job is the shape of the day, being wrong about the shape is the one thing it cannot do. The fix was not to surface more events, it was to give each calendar a role that decides how its events are treated.

This is where the project quietly outgrew its first idea. It started as a presence tool for one person with a tidy set of personal calendars. It became something that models the social and professional texture of a shared, working life, a partner’s schedule and a job, without surrendering the personal space that was the entire point.

Making it stick

Adoption for an audience of one is not a rollout. It is living with the thing and letting daily use rewrite it. Because I was the only stakeholder, I could ship a change, sit with it for an hour, and reverse it before the day was out. Several of the best decisions only surfaced that way. I swapped the calendar and the morning rhythm the moment I saw them in the wrong order. I pulled the Sunday reset back from Saturday evening because seeing reflection prompts before I was ready created exactly the pressure the tool exists to prevent. I changed to-dos to clear each new day, because carrying yesterday’s unfinished list into today is its own quiet guilt. None of those were in the spec. They came from being the user.

Then the brief left the workspace. I converted it into an installable app on my iPad and my Android phone so it could be the thing I tap before anything else pulls at me, no chat interface first. The moment it ran in two places, it stopped being one product and became the same code in two environments that disagreed about something as basic as the Return key.

The bug was precise. On the iPad, typing a to-do and hitting Return saved it. On the phone, Return did nothing. The original code listened for one signal, an Enter keystroke, which is exactly how a laptop and an iPad keyboard behave. It is not how an Android soft keyboard behaves. The fix was to stop depending on one signal and catch the intent however it arrives.

The Sunday reset cards taught a quieter lesson. I reported the same Return bug there and was wrong: those fields had been saving on every keystroke the whole time, even on the phone. The failure was not data, it was trust. The card gave no sign anything happened, so pressing Return into silence felt like pressing into a void. Nothing about the saving logic needed to change. I made the system state visible, a small “saved” note that flashes by the heading, and the dead-feeling tool came back to life. On a presence tool that matters more than it sounds: if I do not trust that my honest Sunday reflection was saved, I stop writing honest ones, and the ritual collapses into hedging. The confirmation is not a convenience. It is what lets me put the phone down and mean it.

Those bugs named a second pattern to sit beside the guilt audit. Call it the assumption audit. The guilt audit asks what a feature does to me emotionally. The assumption audit asks what it quietly takes for granted about where and how it runs: a hardware keyboard, one screen size, a live network, a person who will notice unprompted that their input saved. Each assumption was invisible while the brief lived in one place and became a bug the moment it lived in two. Building for myself does not exempt me from that. It just means I am my own device lab, and I find the assumptions by living inside them.

Impact and results

It became the first thing I open. Not the planner, not email, the brief. It did not replace either existing tool. It filled the exact gap they left, the sixty-second orientation between opening my eyes and picking up my pen, which is the outcome the whole project was aimed at.

The design held its own constraints under real use. A month of daily use added features but never added a streak, an overdue label, or a countdown. Every addition passed the guilt audit first. For a tool built to work against dread, keeping that line while the scope grew is the result that matters.

It survived becoming a real product, not just a nice artifact. It went from a live prototype to an installed app on two different operating systems, absorbed the cross-device bugs that came with that, and kept working when the calendar connection dropped, because missing data was designed to mean an absent section, never an error state. The tool always works. It just has more or less to say depending on what is connected.

It is proof of range. I took this from a feeling to a spec, to a designed system, to a shipped cross-device app, to the debugging that shipping actually requires, on my own and building with AI the whole way. The design judgment and the build are the same story here, which is exactly the point.

Reflections

I would design from feeling first every time. Starting with what I wanted to feel, protecting the journaling practice, and auditing for guilt produced a sharper product than a feature list would have, and letting daily use drive the iteration beat any amount of upfront certainty.

The cost I actually paid was the assumption audit. Building on a laptop and an iPad baked those keyboards’ habits into the product as if they were universal, and I could not see it until I tried to add “call the vet” from my phone on a Tuesday. A team runs a device lab to catch that. I ran a device lab of one, and I only caught it by living somewhere the code had not.

Where it goes next is the personality layer as it settles into daily use, and a deeper tie into my knowledge system so the brief and the archive talk to each other. It is a tool I open every morning, which means it is never quite finished, and that is the right state for it to be in.