Building Northwind, quietly

Northwind started, as most good projects do, as a single overstuffed spreadsheet. Our client — a solo allocator managing a concentrated book — had built a remarkable system out of tabs, formulas, and discipline. It worked, right up until it didn't scale with his thinking anymore.

The brief was deceptively simple: keep everything you love about the spreadsheet, lose everything you hate. What he loved was speed and a sense of total recall. What he hated was that the why behind every position lived in his head, not the sheet.

01 — The shape of the problemTheses, not tickers

We reframed the product around theses rather than holdings. A position isn't a row; it's the current expression of an argument. Every thesis links to the positions that express it and the journal entries that revised it. The portfolio became a document you could read, not just a table you could sort.

A position isn't a row in a table. It's the current expression of an argument you once made.

02 — Build decisionsBoring stack, brave surface

Underneath, nothing is clever: TypeScript, Postgres, tRPC, a single Fly.io region. We spent our risk budget entirely on the surface — a command palette, an event-sourced history so any day could be reconstructed exactly, and a journal that felt like writing rather than data entry.

• Event-sourced core. Every change is an append; “what did I think in March” is a query.
• Keyboard-first. The whole app is reachable without the mouse.
• One user, designed like it. No roles, no orgs, no settings he'd never touch.

03 — Eleven weeksWhat shipping weekly bought us

We shipped to his real account in week three and never stopped. Most features were proposed, built, and either kept or deleted within a single week. By week eleven the spreadsheet was archived — not migrated, archived, because he no longer reached for it.

The quiet metric we're proud of: he stopped mentioning the tool. It became the place the work happened, which is the highest compliment a piece of software can earn.