Work Case study
Daybook
Direct client · Johannesburg
A personal command centre for a founder who was about to hire an assistant to hold his work together. Tasks now file themselves out of meetings, email and calendars, and he only decides.
- ~1 week
- Of build effort, end to end
- ~120
- Postgres RPCs behind row-level security
- ~5 hrs
- Of rework across three weeks of client testing
- 1 PR
- Merged to production by the client himself
The problem
Jon Berkowitz co-founded MotionAds. Like most founders, his real job is being the person everything routes through, and nothing he tried could hold it: Notion, Apple Reminders, pen and paper, a wall of sticky notes. He had hired a personal assistant before, and when we started he was pricing another one.
The problem was never that he needed a task app. It was capture. Tasks were created everywhere, in meetings, in email, in his head at 11pm, but only became visible if he filed them himself, and the manual step is exactly what a drowning founder never gets to. The brief was one sentence: nothing slips through the cracks without Jon doing the filing.
What I built
One core loop: things arrive, Claude proposes, the founder decides. Three AI agents run inside the app, alongside Fathom, Outlook and Google integrations.
-
Capture
Notes, files, WhatsApp, Fathom call summaries, Outlook and calendars flow into a triage queue. Proposals are grouped by the kind of change they make, and bad ones go in bulk.
-
One board
Approved work lands on a Kanban board with categories, parent and child dependencies, and tasks waiting on a named person. A list view groups the same backlog by due date.
-
Work and personal
Separate profiles on the same board mechanics. Buying an apartment is a project with dependencies too, so it gets the same treatment and stays out of the work view.
-
Claude-native
An MCP OAuth server and tools let Claude read and write Daybook directly. A scheduled Claude task reads Gmail daily and files what matters, so there is no Gmail connector to maintain.
My role
Lead developer and the client’s main contact, from the first requirements call to handover. I ran requirements with Jon directly, directed the coding agents and owned quality. Design and brand were handled by a colleague.
I built the schema, row-level security and about 120 RPCs, the MCP OAuth server and tools, the Outlook and calendar pollers, the Fathom webhook, and most of the product surface.
Key decisions
-
AI proposes, a person accepts
Nothing auto-adds to the board. Every proposal waits for approval, which keeps the board trustworthy even when the model is wrong.
-
Let the AI layer do the reaching
Instead of building a connector per service, a scheduled Claude task does the reading. New integrations cost a prompt, not a project, and the client sets them up himself.
-
One line never moves
Claude can change the code, never the production database. That single guardrail is what makes it safe to hand a non-developer the keys.
In the product
Outcome
- A PA, not hired
- Software now does the capture, triage and follow-up a personal assistant would have.
- Four tools, one board
- Notion, Apple Reminders, pen and paper and the sticky-note wall, retired in a weekend.
- Owned and extendable
- The client ships his own changes through Claude Code, behind automated tests and review.
This is 100% what I was thinking, done better and faster, and more sustainably. Nothing else worked, and DayBook works. It literally saved my sanity.