All issues

Case Study Breakdown

Teardown: the inbox that runs itself

A section-by-section breakdown of the Founder Inbox OS — how one feed, one triage layer and one daily brief replaced a 300-email morning.

DashboardLim · Systems desk

2026-06-246 min read

TL;DR

  • Normalise before you automate — one structured feed beats five clever filters.

  • The triage rules belong to the founder; the model just enforces them at scale.

  • Ship the brief first, tune precision second. Trust builds from day one.

Last issue we said the founder inbox is a queue pretending to be a to-do list. This issue opens the hood on the system that fixed it — the same build we wrote up as a case study, told from the decisions that mattered.

Decision one — one feed before any intelligence

The temptation is to point a model straight at Gmail. We didn't. Every inbound email is first normalised into a structured feed — sender class, thread history, attachments, extracted asks — so the triage layer reasons over clean data instead of raw HTML.

That one decision made everything downstream testable. You can replay a week of email through a rule change and diff the output.

Decision two — the founder writes the rules, the model applies them

Triage precision came from thirty plain-language rules the founder already had in their head — "supplier delays outrank new supplier pitches", "anything mentioning a refund is same-day".

The model's job is applying those rules to four hundred messy variations a day, not inventing judgement of its own. That's why precision landed at 92% and stayed there.

Decision three — the brief is the product

The deliverable was never "a sorted inbox". It was one ranked brief every morning — customers first, actions attached, everything else summarised into two lines.

The founder opens one document instead of three hundred threads. Same-day replies stopped being a goal and became the default.

First morning in years I did not open Gmail before coffee.

Founder · anonymised client