{"id":5939,"date":"2026-10-18T18:20:00","date_gmt":"2026-10-18T18:20:00","guid":{"rendered":"https:\/\/www.cmsgalaxy.com\/blog\/?p=5939"},"modified":"2026-10-18T18:20:00","modified_gmt":"2026-10-18T18:20:00","slug":"devops-web-studio-story","status":"publish","type":"post","link":"https:\/\/www.cmsgalaxy.com\/blog\/devops-web-studio-story\/","title":{"rendered":"How a Three-Person Web Studio Stumbled Into DevOps"},"content":{"rendered":"

Nobody at Pixel and Plane had DevOps in their job title. There were three of us \u2014 Maya running clients, Arjun writing code, Tom drawing pixels \u2014 and for four years we shipped websites the way most small studios do: nervously, at night, all at once. This is the story of how we stumbled into a better way of working, mostly by admitting how much the old way cost us. If you build sites for a living, parts of it will feel uncomfortably familiar.<\/p>\n

How DevOps Entered the Studio<\/h2>\n

The wake-up call was a bakery. A lovely client, a relaunch due Friday, and a theme update that quietly broke their checkout at 7pm. We restored a backup by midnight, but the damage was done \u2014 and the damage was not the bug. It was the two weeks of client trust we spent paying it back. That weekend Maya asked an uncomfortable question: why does every launch feel like an emergency? Arjun did some reading and came back with a phrase that stuck: value stream mapping. You trace one change \u2014 a menu update, a new product photo \u2014 from request to live page, and you write down every wait. Ours was mortifying. Client edits waited three days in email. Staging logins waited on whoever remembered the password. Nothing about the waits involved design or code; they were all queueing.<\/p>\n

Month Two: Building the Studio’s DevOps Path<\/h2>\n

February was the plumbing month. Arjun set up a pipeline so that every change we pushed was built once, checked automatically, and published to staging without a human touching an FTP client. Feedback on a change landed in about ten minutes, which sounds like a small thing and absolutely is not \u2014 it meant Tom could see his layouts on a real URL while he still remembered what he was trying. We stopped keeping week-long branches. Everything merged into one trunk daily, small and often, because a pile of unmerged work was exactly what had made the bakery launch a gamble. Client approvals moved onto the staging link itself, so the queue we found in the map quietly disappeared. Maya stopped being a human router between inboxes, which she describes as the closest thing to a promotion she has had in years.<\/p>\n

The DevOps Dip, and the Promise We Made<\/h2>\n

Then came March, and March was worse. Nobody warns you about this: as automation matures, it raises the bar for what counts as done. Our checks demanded more, our deploys expected cleaner work, and for a few weeks we shipped noticeably less while we paid that bill. The delivery literature calls it the J-curve \u2014 quick wins first, a dip while the discipline catches up, then a climb. What saved us was a promise made in February: we agreed, in advance, how long a dip we would tolerate, and told our clients a feature freeze was coming. Because the expectation was set, the dip read as a plan rather than a failure. Studios that skip that conversation usually abandon the whole effort in week five.<\/p>\n

Learning to Roll Back Without Panic<\/h2>\n

April’s lesson was the drill. We had read a documented case where a misbehaving payment service kept a team down for a hundred and ninety minutes because nobody had ever practised the rollback \u2014 and the same manoeuvre, rehearsed, runs about twenty. So we ran one on a rainy Tuesday: Arjun pretended the afternoon’s release was broken, and we timed getting the bakery’s site back to the previous version. First attempt: forty minutes, mostly because nobody knew who was allowed to decide. Third attempt: under fifteen. We also wrote down the one situation where rolling back is forbidden \u2014 a database change already gone live \u2014 and the answer for it instead: migrations now widen a table first and clean up later, so nothing irreversible ever ships. When a real incident hit in May, the post-mortem took an hour on a Thursday, blamed no one, and produced two checklist lines. That habit \u2014 the blameless review inside five working days \u2014 did more for our Friday nights than any tool we adopted.<\/p>\n

Five Things We’d Tell Our January Selves<\/h2>\n