Nobody at Pixel and Plane had DevOps in their job title. There were three of us — Maya running clients, Arjun writing code, Tom drawing pixels — 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.

How DevOps Entered the Studio

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 — 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 — a menu update, a new product photo — 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.

Month Two: Building the Studio’s DevOps Path

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 — 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.

The DevOps Dip, and the Promise We Made

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 — 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.

Learning to Roll Back Without Panic

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 — 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 — a database change already gone live — 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 — the blameless review inside five working days — did more for our Friday nights than any tool we adopted.

Five Things We’d Tell Our January Selves

• Map before you automate. The whiteboard found money that the pipeline never would have.
• Ship small, and let the client watch. Trust compounds faster than features.
• Agree the dip in writing. It saved both the budget and the relationship in March.
• Practise the way back. The first drill is embarrassing; the first real incident without one is worse.
• Blame no one, out loud, as policy. Everything else on this list depends on it.

The Client’s Side of the Story

The bakery deserves a paragraph, because clients live through these changes too. At the start, their owner thought of websites the way people think of plumbing: invisible until it floods, and somebody else’s problem. By March she had a staging link she could actually comment on, which changed her behaviour — small requests replaced dramatic redesigns, because she could see each one land within days. When April’s drill meant she got a call saying “we practised breaking this, here is how we would fix it”, she later told Maya it was the most reassuring conversation she had ever had with a web company. Trust, it turns out, is also a delivery metric; it just never appears on the dashboard.

What DevOps Changed by June

By June the studio felt unremarkable, which turned out to be the goal. Sites shipped in small pieces, several times a week, during daylight. Risky work met one percent of visitors first, canary-style, before the rest. The five delivery numbers the research cares about — how quickly work moves, how often it ships, how soon service recovers, what fraction of changes fail and how much gets reworked — lived on a sticky note, and two of them had actually moved. The five human ones behind CALMS, culture, automation, lean, measurement and sharing, were harder to chart but easier to feel: the 2am messages stopped.

If you run a small web operation, the honest version of this story is that none of it required heroics or an enterprise budget — just a map, one pipeline, a drill and a promise, applied stubbornly for six months while the muscle grew. A practical roadmap to DevOps, SRE and platform engineering is a good next read, and pairs well with a step-by-step guide to planning a business website before development starts if you are building new rather than rescuing old. When sites go wrong for ordinary content reasons instead, the common CMS mistakes worth avoiding make a handy checklist. And when the team wanted the deeper research behind what we had stumbled into, we simply read xOps School’s DevOps reference page and worked through the practices one unglamorous month at a time.