What is a rollback and why does an untested one not count?
A rollback is putting the previous working version back. It only counts if somebody has done it, because the first attempt always uncovers something: a migration that does not reverse, a cache holding the old shape, credentials nobody has. A rollback plan written down and never run is a hope with a procedure attached.
Putting the last working version back, on a path somebody has walked.
Why it matters to you
The cheapest version is the one that shares a path with ordinary work. On octyn.co, rollback is a revert and a push, which is the same path as any deploy, so there is no separate emergency procedure to get wrong under pressure. A build that does not compile never replaces the running container, so a broken commit leaves the live site untouched.
Mobile is different because the store is in the way, so Mooney rolls back through the Play staged rollout: a bad build halts at a percentage instead of being recalled.
The harder case is data rather than code. If the system wrote something wrong to a database, going back to the old version does not unwrite it. That is why rollback questions should always be asked twice, once about the code and once about the rows.
Where this turns up in something OCTYN runs
Each line carries the date it was recorded and where it came from.
- 2026-09-14
Rollback on octyn.co is a revert and a push, the same path as any deploy
docs/growth/case-studies/octyn-site.md, section 5octyn-site → - 2026-09-14
Mooney rolls back through the Play staged rollout, so a bad build halts at a percentage
docs/growth/case-studies/mooney.md, section 5Mooney →
If a proposal used this word and did not explain it, ask.
Book a call →