
What an MVP is and isn't (almost everyone defines it wrong)
The acronym gets used to justify two opposite things: shipping little and shipping badly. The difference matters, especially if you're the one paying for the build.
Read note →Notes on development, design, and the decisions behind them.

The acronym gets used to justify two opposite things: shipping little and shipping badly. The difference matters, especially if you're the one paying for the build.
Read note →
Building a design system for a single-screen project is spending two weeks on flexibility nobody will use. When it's worth it and when it's over-engineering with a fancier name.
Read note →
The hard part of an MVP isn't building it, it's cutting it. The method I use to decide what goes into the first version, with the real decisions behind the SaaS I run in production.
Read note →
A heuristic audit is the cheapest way to find real problems before touching a single pixel. Here's how I run one, and what it surfaced on an e-commerce platform with 34 years in the market.
Read note →
A design token isn't a decorative best practice: it's what turns changing a colour into one line instead of a component-by-component search. How I organize them and how they cross into code.
Read note →
Adding accessibility later means redoing work. The three free checks I run from the very first component, and why they're cheaper in the design than in the code.
Read note →
Most custom projects don't fail because of bad technology. They fail over decisions made in the first week that nobody revisits until it's already expensive to fix. The guide I'd give a client before the first meeting.
Read note →
React, Node, TypeScript — anyone can write that list. What I changed was telling what decision I made and what happened, not which tool I used to make it.
Read note →