Product designer
The problem
Blockers fight you at the moment of starting, which is when the motivation to browse is strongest — so they lose. But opening YouTube was never the real failure. The failure is that a session has no natural end: autoplay removes the stopping point, tabs accumulate, and an hour goes missing without a single decision being made.
The call
Intervene at the end of a video, not the start of a session. The video ending is already a natural boundary — the design just makes it consequential again. Blocking casts the tool as an adversary; closing a tab that has finished its job doesn't. The same logic drives tab switching: when a video ends, focus moves to the next YouTube tab before the finished one closes, so a queue plays through and empties itself. It works with how people actually stack up videos rather than punishing them for it.
What it does
Status
Version 2.0, packaged and in daily use. Not yet submitted to the Chrome Web Store.
The problem
Four people with Letterboxd accounts still spend twenty minutes not choosing a film. Every piece of data needed to settle it is already public — everyone's watchlist, everyone's ratings — but nothing joins it together.
The call
The obvious build is an intersection: show the films on everyone's watchlist. I built that, and it returns almost nothing. Watchlists are long and personal, so genuine overlap is rare — the honest result is an empty screen. So the product has a second tier: films one person wants to watch that another has already rated highly. That's an endorsement rather than an agreement, and it's the tier that actually ends the argument. Designing for the empty state first is what produced the real feature.
What it does
Status
Deployed and in use at version 0.28. Open work is concentrated on very large watchlists, where the source sits behind a rate limiter and results have to stream in progressively.
The problem
The collection is seven themed chapters, not a flat playlist — the sequence carries meaning that a standard player destroys the moment it renders everything as one list. On a phone the problem compounds: less room, and every control has to be reachable with a thumb while walking.
The call
Build a genuinely separate mobile interface rather than responsively shrinking the desktop one. The desktop player's central interaction is a segmented progress bar you scrub across an entire chapter — a precision-pointer gesture that is simply not available on a phone. Shrinking it produces targets nobody can hit. So mobile gets its own grammar: a chapter selector as the primary control, a segment bar retuned with touch-sized targets, and dropdowns for tracklist and chapter instead of persistent navigation. Same data, different interaction model, chosen at the routing layer rather than in a media query.
What it does
Status
Complete and deployed.
The problem
Note apps take custody of your writing — it lives in their database, in their format, on their terms. Plain files on disk have none of that problem and no decent interface. Nothing occupies the middle: the immediacy of a sticky note, writing real Markdown into folders you chose.
The call
Treat "where does this note live" as a visible, first-class part of the interface rather than a setting buried three menus deep. Each note has a primary save location and an optional second one, and the two can differ in both filename and format — so the same note can be Markdown in a project folder and clean .txt in an archive, with the Markdown syntax stripped on the way out. Smart Notes invert the relationship entirely: bind a note to a folder and it displays that folder's most recent file, which turns a note into a live window onto work happening elsewhere.
What it does
Status
In active development at version 0.7.x, used daily.