How We Work

We’re a small team. That means everything we do has to be deliberate — we don’t have the headcount to waste on process for its own sake.

Here’s how we actually work.

Short cycles, real deliverables

We work in roughly six-week cycles. At the start of each cycle, we pick a small number of things to build — usually two or three — and we commit to shipping them by the end. Not “making progress on them.” Shipping them.

This sounds obvious, but it has a real effect on how we scope work. If a feature can’t be finished in six weeks, it needs to be smaller. We don’t carry unfinished work forward; we either ship it or we cut it and reconsider.

Asynchronous by default

Most of our communication is written and async. We don’t have daily standups. Instead, we write short updates when something notable happens — a decision made, a problem discovered, a piece of work done.

This means anyone can catch up on project status in five minutes without needing to be in a meeting. It also means we think more carefully before asking for someone’s attention, because we’re writing it down rather than just interrupting.

Small teams, clear ownership

Each project has one person who owns it. Not a committee, not a rotating responsibility — one person who is accountable for the outcome and empowered to make decisions.

That doesn’t mean they work alone. But it means there’s always a clear answer to “who decides this.”

Why this works for us

The short version: it keeps us honest. Six-week deadlines with real deliverables make it hard to hide behind process. Async communication means we spend time building instead of talking about building. Clear ownership means decisions get made instead of deferred.

We’re not claiming this is the right way for everyone. But for a small team shipping software under real constraints, it works.