How I designed and built DayDeskr — and what I’d do differently

01 — ChallengeDayDeskr started as a dogfood of my own habits: I kept re-planning my day in tools built for other people’s jobs. The brief I wrote myself was deliberately tight — set up in under a minute, no account wall, honest about what a working day actually looks like. This section is where each case study names the problem in one paragraph, in plain language.

Process, in public

02 — ProcessThe build-in-public journal in Writing is the raw record; this case study is the edited version. Three habits carried the work: a weekly shipping rhythm, writing before building when the problem was fuzzy, and treating scope decisions as design decisions with the same care as any screen.

When I got stuck I asked the question out loud in the journal — twice the answer arrived in the replies. That feedback loop shaped more of the product than any roadmap did.

The decisions that mattered

03 — DecisionsThree calls stand out. Each one reads as a trade-off, because that’s what a decision is.

• Small screens first. A day plan is a pocket thing; the desktop layout earns its place later. It cost a month of interface restraint.
• No accounts to start. Let people feel the flow before we ask for anything — then make the account worth it.
• One data model, owned by me. No external service that could change its terms and take the product down with it.

What happened

04 — OutcomeThe honest version: it shipped, it’s live, and it’s in daily use by people who aren’t me. The unflattering version lives in the journal — the features that flopped, the estimate that was off by three weeks, and the v2 cuts that made it better. Case studies here report both, because a portfolio that only shows the wins isn’t doing its job.