Two people run the travel guide you are reading: one editor who writes about the lakes and the old town, one developer who keeps the site standing. For years our launch ritual was identical — finish the new section at night, throw it live, and fix whatever readers found by morning. It worked, in the way a scooter without brakes works on a flat road. Then we spent one season actually doing ReleaseOps, the release discipline described in the Ops Atlas entry on the practice, and this is the honest account of what changed for a team our size.
Why a two-person team bothered with ReleaseOps at all
The trigger was embarrassment, not ambition. We pushed a redesigned version of our most-visited page — the guide covering Bhopal’s attractions, heritage lakes and day trips — and the map component silently died on phones. For six hours, the majority of our readers saw a page with a hole in it. Fixing it took eleven minutes. Knowing about it took six hours, because the only monitoring we had was a reader’s email. A friend who runs delivery at a software shop looked at our setup and said the quiet part out loud: nothing in our process could have told us earlier, because we had no separation between “it is on the servers” and “people can see it”.
The ReleaseOps changes we could actually afford
We could not copy an enterprise pipeline, so we took the cheapest useful pieces. First, the two-moment split: every change now installs silently, visible only to us through a private preview, before anyone else can touch it. Second, a ring order written on a sticky note that has since become a page in our handbook: the two of us, then five friends across three cities who agreed to click around, then a thin slice of real visitors, then everyone. Third, a waiting gap between rings — a few hours at least, overnight for anything touching money or bookings. Fourth, every toggle we add to control behaviour gets written into a register with the date it should be removed, and the register is checked at the start of each month.
That last habit sounds fussy for a two-person operation, and it earned its place in one bad week. An old toggle from a monsoon-promotion experiment stayed in the wiring for a year because nobody remembered which parts depended on it — a small debt that cost a full evening to untangle and taught us the phrase for it. Now toggles come with removal dates the way library books come with return dates, and the difference is that ours actually get returned.
What ReleaseOps felt like from the inside
Honestly? Slower, for about three weeks. Then something inverted. The launch of our section on the best things to do around Bhopal was the first big test: new layout, new photo gallery, a booking widget we had written ourselves. Under the old ritual, that would have been a nervous midnight. Instead it installed dark on a Tuesday, our friends in Indore and Sehore found two broken links on Wednesday, the five-percent ring ran Thursday without a murmur, and Friday everyone got it. Total reader-facing problems: zero. Total adrenaline: also roughly zero, which was strange at first and then wonderful.
The instrumentation we adopted is proportionate to our size — one dashboard, three numbers. How quickly a bad change gets noticed (the friend-ring made this minutes instead of hours). How long until the site is safe again when something breaks (a rehearsed return path cut this from an evening to a coffee break). And how often we pull back a change that turns out fine — a number we track mostly to keep ourselves honest, because panic-rollbacks are their own kind of waste. A colleague at a bigger firm tells us they also count reader-minutes burned by each faulty release, and one day, if we grow, we will too.
The ReleaseOps lessons we keep retelling each other
- Anything readers can feel is a release. Our worst near-miss of the season was not code at all — it was a data import that moved every listing’s opening hours by thirty minutes.
- The return journey needs rehearsing more than the launch. We now practise rolling back once a quarter, timed, and the first drill was humbling.
- Small audiences cannot support clever statistics. Fancy percentage rollouts need traffic we do not have; patient rings with waiting gaps suit a guide like ours far better.
- Freeze the right things. Our blanket December halt achieved nothing except moving breakage to January; a short, targeted pause around the tourism peak, plus an automatic halt when the site has already had a rough month, does the actual job.
- Approval by committee is not safety. A second pair of eyes that understands the change, plus checks that leave a record, beat any WhatsApp group of well-wishers.
Where ReleaseOps leaves a small team
A season in, the practice has stopped feeling like a borrowed software ritual and started feeling like ordinary editorial care — the same instinct that makes a good editor read a piece aloud before publishing, applied to the machinery. Our pipeline now carries a collaboration we could not have risked a year ago, a syndicated set of Kerala events and travel guides, rolled out ring by ring with the boring confidence we used to envy in bigger teams. Two people, one register of toggles, a sticky note that became a page, and no more six-hour holes. If a guide this size can run releases this way, the barrier was never headcount. It was the habit of treating launch day as a leap instead of a walk.
