How a Small Team Ships Products That Feel Bigger Than They Are

The size question

People who know us sometimes express surprise when they see the breadth of what we've built. Multiple live products, a library of free tools, a design system, this blog — the assumption is that it must come from a larger team than it does.

Ruthless prioritisation

The primary mechanism that lets a small team punch above its weight is saying no to the right things. Our prioritisation question: if we do this and nothing else this week, will the product be meaningfully better for the users who matter most to us?

Design does heavy lifting

Design quality is the multiplier. A small team that invests seriously in design can produce something that feels larger, more considered, and more trustworthy than a larger team that doesn't.

Systems over heroics

A small team that relies on individual effort for everything that matters is a fragile team. Build systems — processes, automations, and structures that run reliably without requiring someone to be watching.

Saying no, loudly

One of the harder skills in a small team is saying no to users — specifically, to feature requests from users you like and respect. A small team that says yes to every feature request ends up building a product that is everything to a few people and nothing to anyone else.

What we genuinely can't do

There are things a small team genuinely cannot do: compete in markets where distribution requires massive sales teams, support enterprise contracts with complex compliance requirements, or ship features at the speed a well-funded competitor with fifty engineers can maintain.