Shipping four products: our weekly rhythm

Four products alongside client work sounds like a recipe for chaos. What keeps it workable is not heroics, it is a boring weekly schedule that we mostly stick to.

The shape of the week

Monday: support and triage

Every inbox gets cleared first. Bug reports are reproduced, labelled and either fixed that day or scheduled. Starting with users keeps the rest of the week honest about what matters.

Tuesday and Wednesday: building

Two uninterrupted days on one product at a time. Notifications are off, and no meetings are booked. Most of the actual feature work happens here.

Thursday: review and prepare

Code review, testing and release notes. Releases are prepared on Thursday but not shipped on Thursday afternoon.

Friday: writing and planning

Documentation, blog posts, changelogs and next week's plan. Writing forces us to explain what we built, and explaining often exposes what we got wrong.

Why nothing ships on a Thursday afternoon

If something breaks, a Thursday-afternoon release gets fixed at night or sits broken until the weekend. We ship on Tuesday or Wednesday mornings, when there is time to watch it and roll back.

One product per block

Rather than touching all four products every day, each building block belongs to one product. The cost of switching between codebases is mostly the cost of reloading context, so we avoid doing it more than once a day.

What does not fit

Incidents ignore the schedule. When something is down, everything else stops. We keep slack in the plan by only committing to about three-quarters of the available time.

What we would change

The schedule only works if every block stays protected, and knowledge can still pool around whoever built a feature. Part of the plan for this year is documentation good enough that any engineer could pick up any of the four products.

Try it yourself

You do not need four products for any of this to be useful. Pick a day for support, a day for writing, and a day you never deploy, and see what changes.