Shipping weekly without burning out

The shipping cadence

We ship to production every Wednesday. Not a "release window" — actual production, actual users, actual consequences. It's the most important thing we do as a company, and we've designed our entire process around making it sustainable.

The week

Here's what a typical week looks like:

• Monday — async planning. Everyone writes a short post: "here's what I'm shipping this week, here's what I need from others." No meeting.
• Tuesday — code freeze at 5pm. Feature flags on for new stuff. Final review.
• Wednesday — ship at 10am. Pair on rollout. Monitor for 2 hours. Roll back if anything's wrong.
• Thursday/Friday — fix bugs from the release. Start the next week's work.

Small batches

The secret to shipping weekly is shipping small. A 2-week feature is a 1-week feature that took twice as long. We break work into chunks that fit in a week — if it can't fit, it's too big and we split it further.

This is uncomfortable at first. Designers want to ship a complete redesign, not a piece of one. Engineers want to ship the full refactor, not a first step. But small ships compound — 50 small ships in a year is more progress than 4 big ones, and the team stays sane.

The "no heroics" rule

If shipping this week requires someone to work late, we don't ship this week. Period. The release slips to next week. We've never regretted this rule.

Heroics are a tax on next week's shipping. The person who pulled the all-nighter is useless for 3 days afterwards. The bug they introduced at 2am takes twice as long to fix as it would have taken to ship it fresh on Monday.

What we don't do

• No release meetings. The release goes out via a script. If you need a meeting to release, your process is too risky.
• No change approval boards. The engineer shipping the change is the approver. We trust our people.
• No "release candidates." Production is the release candidate. Feature flags + gradual rollout + fast rollback beat staging environments every time.

The honest part

This process works for us, at our size (28 people), in our market. It's not a prescription. But the underlying principles — small batches, no heroics, async-first — are universally applicable. Steal what's useful, ignore what's not.