Blog

Notes on development, design, and the decisions behind them.

Comparison between a small working product and an incomplete version
4 min read

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 →
Library of interface components organized hierarchically
3 min read

What a design system is (and when you DON'T need one)

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 →
Product scope diagram showing features inside and outside the first version
5 min read

From idea to MVP: how I decide what to build and what to leave out

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 →
Usability heuristics checklist over an interface
4 min read

How I audit an interface with Nielsen's 10 heuristics

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 →
Colour palette organized into primitive and semantic token layers
4 min read

Design tokens: how what I design in Figma ends up as Tailwind config

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 →
Interface with keyboard focus indicators and colour contrast markers
4 min read

Why accessibility can't be a phase 2

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 →
Checklist for hiring a custom software development project
4 min read

How to hire custom development without it spiraling out of control

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 →
Résumé comparing a generic description with a specific decision description
3 min read

My résumé stopped being a list of technologies, and conversations changed

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 →