# Releases without fear: rollback and feature toggles > A module case: a late-night release goes wrong, and the habits that limit the damage: small releases, a quick rollback, a feature toggle for anything new and a calm apology. - Course: [From Idea to Profitable Product: Building Without Investors](https://productovi.com/courses/bootstrapped-product.md) - Module: The smallest thing that works - Lesson 16/30, ~34 min - Source: https://productovi.com/courses/bootstrapped-product/releases-without-fear ## 17 April, 23:40 **Alex Tutor:** GarageDesk has been live for six weeks, and you're still advising its founders with me. Today: how to roll back a bad release and ship without fear. Nina, tell us about Thursday night. **Nina:** At 23:40 I released new reminder templates: nicer text, the shop's phone number at the bottom. The new code treated that day's reminders as unsent and sent them again. **Oscar:** A few minutes later Greg called me. 140 of his car owners got a second reminder just before midnight, and some were already replying "why twice?" **Sofia:** What did you do? **Nina:** Redeployed the previous version. Six minutes from Greg's call to the rollback. **Alex Tutor:** Six minutes is good, and it worked only because the previous version was one command away. Let's look at what limited the damage and what made it bigger. > **Exercise:** At 23:40 on 17 April Nina released new GarageDesk reminder templates, and the new code sent that day's reminders a second time: 140 car owners of Greg's shop got a duplicate just before midnight. Six minutes after Greg called, the sending had stopped. What limited the damage most? ## Small releases, one change at a time **Alex Tutor:** What else was in that release? **Nina:** The templates, a faster car-entry form and a change to how the day's sending list is built. Three weeks of work. **Alex Tutor:** So when the duplicates appeared, any of the three could be the cause. Release small changes often, ideally one change per release. When something breaks, you know what broke it. ![An overloaded truck stacked with three different crates wobbles on a road while a small van carrying a single box drives steadily beside it.](https://productovi.com/courses/bootstrapped-product/inline/releases-without-fear-illustration-2.webp) **Sofia:** Isn't releasing often riskier? More chances to break something. **Alex Tutor:** Each small release is less risky and easier to undo. A big one piles up changes that nobody can check together, and customers suddenly find everything different. > **Exercise:** **True or false:** releasing rarely, in big batches, is safer, because there are fewer releases that can go wrong. ## A rollback plan and a feature toggle **Alex Tutor:** Rule: never release what you can't undo. That means the previous version ready to roll back with one command, database changes that can be reversed, and for anything new, a switch. **Nina:** A switch? You mean a feature flag? **Alex Tutor:** Yes, a **feature toggle**: on/off for a new feature, per shop. The new templates go live for one shop, you watch a day of sending, then turn them on for the rest. If something looks wrong, flip it off without a release. ![A row of small garages, each with its own wall switch; only the first garage's light is on, and the founder watches it closely.](https://productovi.com/courses/bootstrapped-product/inline/releases-without-fear-illustration-3.webp) *Never release what you can't undo, and try it on one shop before all.* **Nina:** Dennis goes first. He likes being first. ![Release one small change, switch it on for Dennis only, watch a day of sending, then turn it on for the rest; if something looks wrong, flip it off without a release.](https://productovi.com/courses/bootstrapped-product/diagrams/m4-l4-switch-rollout.png) *One shop first, then everyone.* **Alex Tutor:** Picture the first day with Dennis. Something looks off; what does the switch let Nina do? > **Exercise:** GarageDesk's new reminder templates sit behind a per-shop on/off switch, and Nina has turned them on for Dennis's shop only. By noon, several car owners reply "what is this number?". What should Nina do first? > **Exercise:** Put the steps for rolling out the new reminder templates safely in order. ## When to release: timing and guard rails **Sofia:** Was 23:40 the mistake? Nobody uses the app at night. **Alex Tutor:** The app is quiet at night, but GarageDesk sends messages to real people. Release when you're fresh enough to watch, and when a mistake can't wake anyone up. **Alex Tutor:** Nina has the sending-list change ready to go. Two slots are free this week. > **Exercise:** GarageDesk sends reminders by SMS and Viber to the car owners of 14 shops. When should Nina release a change to how the day's sending list is built? **Nina:** So: releases on weekday mornings, never on Friday evening. And no reminders at all between 21:00 and 9:00, whatever the code says. **Alex Tutor:** That last rule is a guard rail. It doesn't prevent bugs, it limits how much harm any bug can do. **Alex Tutor:** Let's make sure that difference is clear: preventing a bug versus limiting its harm. > **Exercise:** Which of these is a **guard rail**: it limits the harm of any bug rather than trying to prevent bugs? ![A car takes a sharp mountain curve and brushes safely against a sturdy guard rail at the edge.](https://productovi.com/courses/bootstrapped-product/inline/releases-without-fear-illustration-4.webp) > **Exercise:** Which habits reduce the harm a bad release can do to GarageDesk's shops? Choose all that apply. ## The apology **Oscar:** At 8:00 I wrote to Greg and Martha: what happened, that it was fixed, and what we changed so it won't repeat. Then, with Greg's OK, one short message to the 140 car owners under the shop's name. **Sofia:** Another message? Didn't that make it worse? **Oscar:** Greg wanted it. Half of them had already asked "why twice?", and the other half would ask Martha at the counter. **Alex Tutor:** Fast, honest and specific: what broke, what's fixed, what changes. A bug handled well can build more trust than a quiet month. Greg stayed, and by the end of April GarageDesk had 14 paying shops. **Alex Tutor:** Before you write Oscar's message to the shop, settle the question that worried you about the car owners. > **Exercise:** **True or false:** after a faulty release sent 140 car owners of Greg's shop a duplicate reminder just before midnight, and some of them replied “why twice?”, GarageDesk should not message the 140 car owners again, because any extra message only makes things worse. > **Exercise:** At 23:40 on 17 April a GarageDesk release re-sent that day's reminders: 140 car owners of Greg's shop got a duplicate just before midnight. Nina rolled back six minutes after Greg called. GarageDesk now adds a 21:00–9:00 window with no reminders, per-shop switches for new features and one change per release. Write Oscar's 8:00 message the next morning to Greg and his administrator, Martha (3–5 sentences). ## The module case **Alex Tutor:** Let's put the whole module together: a solution that fits the working day, the smallest version, what to rent and how to release it. **Oscar:** Martha has a new request. Car owners reply to reminders, "book me for Tuesday", and she copies every reply by hand into her notebook. **Nina:** I already want to write our own two-way messaging. It would be fun. **Sofia:** Can I plan this one before Nina starts coding? > **Exercise:** Plan how GarageDesk should handle car owners' replies to reminders. > **Key ideas** > > - Release **small changes often**, ideally one per release, so a problem points straight at its cause. > - Never release what you can't undo: the previous version one command away, reversible database changes. > - Put new features behind a **per-shop on/off switch**: one shop first, a day of watching, then everyone. > - Pick release times for the people affected: weekday mornings, and no customer messages at night (GarageDesk: none between 21:00 and 9:00). > - After an incident, tell customers fast what broke, what's fixed and what changes. **Alex Tutor:** Next module: GarageDesk has paying shops, all in Vinnytsia. Is the market big enough for two founders? - Previous lesson: [Build vs buy: ready-made instead of your own](https://productovi.com/courses/bootstrapped-product/ready-made-instead-of-your-own.md) - Next lesson: [Ideal customer profile: narrow or widen the niche](https://productovi.com/courses/bootstrapped-product/narrow-or-widen-the-niche.md) --- Productovi Learning. Free, no sign-up needed to read.