Why Shipped releases small changes every week instead of saving them up, and what that habit does for risk, feedback and the people paying for the work.
Every Thursday, something we built goes live. Sometimes it’s a new feature. Sometimes it’s a fixed date picker or a faster search page. Occasionally it’s a single line of copy. It’s never nothing, and it’s rarely large.
That rhythm isn’t an accident. It’s the most important habit we have, and it shapes almost everything else about how we work.
The big release problem
Most software projects we inherit have the same history. Months of work piled up on a branch. A launch date that slipped twice. A release weekend where everything changed at once, and then a week of figuring out which of those changes broke checkout.
Big releases feel efficient. You do the testing once, you write the announcement once, you deal with the nerves once. But the cost doesn’t go away, it just arrives all at the same time. When a hundred things change together and something goes wrong, you have a hundred suspects.
What small buys you
When a release contains three changes, a problem has three possible causes. You can usually find it in minutes. Often you don’t even need to: you roll back, look at it calmly the next morning, and ship the fix the following week.
Small batches also make the work easier to review. A pull request someone can read in ten minutes gets read properly. One that takes an afternoon gets skimmed and approved because everyone wants to go home.
And small changes are easy to undo. That one fact takes most of the fear out of deploying, which means people deploy more, which keeps the batches small. It’s a loop that feeds itself, in the good direction for once.
Feedback while it still matters
The other reason is that we’re usually wrong about something. Not badly, just in the ordinary way that anyone building for someone else is wrong. The button is in the wrong place. The report needs one more column. The feature nobody asked about turns out to be the one everyone uses.
If we find that out in week two, it’s a small adjustment. If we find out in month six, it’s a rework, a budget conversation and a slightly awkward call. Shipping weekly means our clients see real software, on real data, almost from the start. Their reactions steer the next week’s work instead of arriving as a list of surprises at the end.
A week, in practice
Our week is simple on purpose:
- Monday: we agree with the client what’s going out on Thursday. Usually two to five items, each small enough to describe in a sentence.
- Tuesday and Wednesday: we build, review and test. Anything that won’t be ready gets cut or split, not rushed.
- Thursday: we deploy in the morning, check the dashboards, and send a short note covering what changed and what to look at.
- Friday: we tidy up, fix anything small that Thursday turned up, and write down what we learned.
No release goes out on a Friday afternoon. That rule has saved more weekends than any tool we own.
What it asks of us
Shipping every week isn’t free. It needs a deploy process you trust, so pushing a release is boring rather than brave. It needs tests that catch the obvious mistakes. It needs feature flags, so half-built work can live in production without anyone seeing it. And it needs the discipline to split big ideas into pieces that are each worth having on their own.
That last part is the hardest. “Build the new billing system” is not a week of work. “Show customers their next invoice date” is. Learning to find that first useful slice, and then the next one, is most of the craft.
What it gives our clients
For the people paying for the work, the weekly rhythm turns software from a promise into a habit. They don’t wait three months to find out whether the project is on track. They can see it, every Thursday, in the product itself.
It also changes the shape of the risk. If the budget runs out early, or priorities shift, they still have everything we’ve shipped so far, working and in use. There’s no half-finished branch that only pays off if the whole plan survives.
Leaving the harbor every week
None of this is new. Teams have been preaching small releases for decades. What surprises us is how rarely it actually happens, especially for small companies working with outside help.
So we made it the default. Not a goal, not a phase we’ll get to after launch. Every project, every week, from the first Thursday on.
If that sounds like the way you’d like to work, we should talk.
