Skip to main content
Case study

Resolution

YEAR
2026
ROLE
Designer & Engineer
STACK
Next.js · TypeScript · WebGL · tldraw

What I was trying to figure out: why every thinking tool I'd used left me with more notes and no more clarity. I had years of Notion, of Obsidian, of a thousand .txt files. What I didn't have was the feeling of a problem getting sharper over time — the thing that actually happens when you stay with something long enough. The tools were good at capture. None of them were built around the slow work of seeing.

Context

Resolution started as a complaint. I kept noticing that my best thinking didn't look like a list — it looked like a few ideas I could see in high detail surrounded by a lot of fog. The detailed ideas weren't smarter; I'd just spent more time looking at them. "Resolution" became my private word for that: how sharply you can see a problem before you try to solve it. You can't solve something at a lower resolution than you can see it, and most tools quietly assume you already see it clearly.

So the brief I gave myself was narrow. Not a second brain, not a knowledge graph. One verb: resolve. A space where an idea could start as a blurry smudge and, with attention, become something you could see every edge of.

Approach

I built it as a spatial canvas rather than a document because documents have an order and thinking doesn't. The first prototype was a weekend of WebGL — just nodes you could drag, with one rule: a node's size mapped to how resolved it was. Vague things were small and soft. Things you understood were large and crisp. That single mapping did more work than any feature I added later. You could open a board and feel where your understanding was thin.

Everything after that was subtraction. I kept asking what I could remove and still have the tool make sense. No folders. No tags. No sidebar. The render loop got most of my attention — I spent an embarrassing amount of time making a node feel like it settled when you let go of it, the way ink does on paper, instead of snapping like a UI element. That sounds precious. It's the difference between a tool you tolerate and one you reach for.

Decisions

Size means resolution, not importance. The obvious version maps node size to priority. I tried it; it turned the canvas into a to-do list with extra steps. Mapping size to how well you see the thing instead kept the tool honest about its one job. A huge node you barely understand is a lie the interface won't let you tell.

Keyboard-first, eleven shortcuts. I capped the command set at what I could memorize in a sitting. If a feature needed a menu to be discoverable, it was a sign the feature was wrong, not that I needed a menu. The constraint killed at least three half-built panels.

No collaboration in V1. Resolution is a thinking tool, and thinking is mostly something you do alone. Multiplayer would have meant presence indicators, conflict resolution, an account system — a different product. I shipped the single-player tool I actually wanted and left the rest as a maybe.

Local-first storage. Boards live in the browser and sync to a file you own. I didn't want the tool to depend on my server staying up, and I didn't want anyone's thinking held hostage by a subscription. It made the build harder and the product calmer.

Outcome

It shipped as a small, fast web app, and it's now the thing I open before starting any project — including the redesign of this site. The honest outcome is personal: I think more clearly with it, and I can watch a fuzzy idea get sharp across a week instead of pretending I had it figured out on day one. A few hundred people use it. Some of them write to tell me it changed how they plan; more of them, I suspect, bounced off the emptiness of the empty state. That's a fair trade for a tool with one opinion.

The technical outcome I'm proud of is dull to describe and good to use: it holds a thousand nodes at sixty frames without the fans spinning, because the render path was the first thing I built, not the last.

Lessons

I over-built the sync layer. Local-first was right, but I spent weeks on conflict cases that a single-player tool will almost never hit. I'd ship the dumb version first next time and earn the complexity only when a real user hit a real conflict.

I also waited too long to show it to anyone, because the empty state embarrassed me. When I finally did, the feedback wasn't "add features" — it was "I don't know what to put here first." The fix was a single line of onboarding copy, not a tour. I'd trade a month of polish for that one sentence earlier.

The deeper lesson is the one the tool is named after: the resolution of the product lagged the resolution of my idea for a long time. I could see what Resolution should be months before I could build it. The work was mostly closing that gap — which is, I think, what all building is.

Credits

Solo build. The canvas rendering owes an obvious debt to tldraw, whose source I read more than once. Early testers Mai and Tâm caught the empty-state problem I was too close to see.

The empty state. One node, no chrome — the whole tool is the canvas.
Size maps to resolution. The things you understand best are biggest and sharpest.
The render loop was tuned to feel like ink settling, not a database updating.
Eleven shortcuts, no menus. If it needed a menu, it didn't ship.
A month of thinking about one project, seen from orbit.