पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 09 · Build
Shipping weekly: the cadence that compounds
A small team that ships every week, tells customers what changed and reads the result runs fifty experiments a year. One that ships quarterly runs four, and cannot tell which of its changes worked.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Most small teams do not decide to ship slowly. They decide to ship one more thing first, and the release that was meant to go out on Friday goes out three weeks later carrying eleven changes, two of which break something and none of which anyone can measure on its own. The cure is not working harder. It is a calendar.
This lesson sets up a weekly release rhythm a team of three to fifteen can keep: the release train, the small batches and flags that make it safe, the four numbers that tell you it is working, the changelog that turns each release into a conversation with customers, and the one-week loop that turns it into learning. The figure in the middle shows why batching costs more than it appears to.
Why cadence compounds
Darragh Curran’s 2013 essay for Intercom, Shipping is your company’s heartbeat, makes the case in one line: software only becomes valuable when you ship it to customers. Until then it is effort and untested assumptions. He adds that release cadence shapes the company around it. A yearly cycle breeds heavy planning up front, and a long time to production means fixes get batched, delayed or forgotten, and customers notice.
Paul Graham’s Startups in 13 Sentences puts the learning argument second on his list: launch fast, because launching teaches you what you should have been building. A weekly cadence is that sentence applied fifty times a year rather than once. The arithmetic behind it comes from the 2009 Microsoft paper by Ronny Kohavi and colleagues: only about one third of ideas improve the metrics they were designed to improve. If two in three changes do not do what you hoped, the team that finds out fastest, and keeps only what works, compounds. The team that finds out quarterly is still guessing.
The release train
The core rule is borrowed from railways: the train leaves at a fixed time and does not wait for a late passenger. Pick a release day. Whatever is merged, tested and behind a flag by the cut-off goes; whatever is not waits a week. Nobody negotiates the departure time, which removes the most common cause of slipping releases, the one more thing.
Facebook’s engineering team described how far the idea scales. Its website was pushed three times a day from a release branch cut weekly, and by 2016 a weekly push could carry as many as 10,000 changes. It moved to pushing from the main branch every few hours, completed in April 2017, with each push going to employees before production. Its mobile apps moved from a four-week release to two weeks and then to one, with release candidates available daily to about a million Android beta testers. A seven-person team has none of Facebook’s tooling and does not need it. It needs the same shape: a fixed day, a stage where your own team uses the release first, and a rule that the train leaves.
A version that fits a small team: Monday, agree the week’s changes. Tuesday evening, the cut-off. Wednesday, the release goes to the team and to five friendly customers. Thursday morning, it goes to everyone and the changelog goes out. Friday, read last week’s release. Mobile apps add store review time, so cut on Monday and submit on Tuesday; web products can ship daily inside the same weekly rhythm.
Small batches, flags and the four numbers
A weekly train is only safe if each change is small and can be switched off. Keep branches short-lived and merge daily. Put anything a user would notice behind a feature flag, so code can ship dark and be turned on for the team, then for a few customers, then for all; a flag that cannot be turned off within minutes is not a flag. Write the rollback before the release, not after the incident.
Cutting work to fit a week
The objection every team raises is that real work does not fit in a week. Most of it does, once it is cut the right way. Cut vertically, not by layer: the first slice of a new billing screen is one invoice type working end to end for one customer, not the database tables for every invoice type. Ship the scaffolding dark: a feature that needs six weeks can ship six times behind a flag, visible only to the team, and be switched on when it is whole. Change data in steps: add the new column, write to both, move the readers, then remove the old one, each step a separate release that can be undone. And separate the deploy from the launch: code reaches production every week, while customers see a feature when the flag is turned on, which can be timed for the changelog, a sales conversation or a quiet Tuesday.
Some work genuinely does not cut: a regulator’s format change that must land complete, a migration to a new payment gateway. Put it on the train anyway as a series of dark releases, and keep the train running for everything else. The cost of stopping the train for one large change is that every small change waits behind it, which is exactly the batching the cadence exists to avoid.
Measure the system with four of the DORA software delivery metrics, the research programme’s standard measures of how teams ship: deployment frequency; change lead time, from commit to running in production; change fail rate, the share of deployments that need an urgent fix or rollback; and failed deployment recovery time. DORA’s research, in its own words, has repeatedly shown that speed and stability are not trade-offs. Teams that ship more often also break less, because each release is small enough to understand. For a weekly train the targets are plain: at least one production release a week, a typical change live within a week of being written, fewer than one release in six needing a hotfix, and recovery inside an hour.
The figure holds the amount of work constant: fifty changes a year either way. What changes is whether each change can be judged on its own. Shipped weekly, a change that hurts the metric is noticed and removed. Shipped in a quarterly batch of a dozen changes, a winner and a loser cancel out, the batch looks flat, and the team cannot say which change did what. At the defaults the weekly team ends the year well ahead and can name its winners; the batching team has kept its losers along with its winners.
The changelog is the product talking
Every release gets a changelog entry the same day, written for customers rather than engineers: what changed, who it is for, and one sentence on why. Three to five lines a week is enough. Post it where customers already are: an in-app note, an email to admins, a WhatsApp broadcast for products whose users live there. Then do the part almost nobody does. Find every customer who asked for a change that shipped, and tell each one by name that it is live. A founder who writes ten such messages a week turns feature requests into proof that asking works, and it is the cheapest retention activity there is.
The changelog also disciplines the team. A week with nothing worth writing is visible, and a month of entries that customers would not notice says the roadmap is full of internal work. Read it as a product document: fifty entries a year is the honest record of what the company did.
Fifty small releases a year are fifty chances to find out you were wrong. Four big ones are four chances, and you will not know which part was wrong.
Closing the feedback loop
A release is not finished when it ships. It is finished when the team knows what it did. One week after each release, check the metric each change was meant to move, using the five-part bets from [the roadmap lesson](/library/roadmap-as-set-of-bets) where you have them. Read the support queue for the week and tag anything the release caused. Call or message three users who touched the changed part of the product and ask what they did with it. Then decide for each change: keep, fix or remove. A change nobody used after two weeks is a candidate for removal, because every feature left in the product is a cost the team pays on every future release.
The weekly ritual
Monday, fifteen minutes: agree the changes for this week’s train, each one small enough to ship behind a flag. Tuesday: cut-off; anything not ready waits. Wednesday: the release goes to the team and a handful of friendly customers. Thursday: release to everyone, publish the changelog, message each customer who asked for something that shipped. Friday, thirty minutes: read last week’s release against its predictions, decide keep, fix or remove for each change, and write down the four DORA numbers for the week. Fifty Fridays of this is a year of learning on paper, and a team that has shipped fifty times has also stopped being afraid to.
The figure is a model with assumptions you can change, not a forecast; the Facebook and DORA figures are from the sources below.