Meet Karo and Devan. Three years ago they were helping relatives navigate visa appointments, keeping notes in spreadsheets, and complaining — the way you do — that nobody had built a decent reminder service for the whole exhausting process. So they built one. Five people, one product, customers in eleven countries, and a problem familiar to every tiny team in every industry: who looks after the servers while everyone else is building features?
Their company has no operations department and never will — they are, in the industry’s borrowed vocabulary, a NoOps team. That sentence, which used to sound like science fiction, now describes thousands of small businesses, and yet the interesting part of their story is not the absence of an ops team. It is everything the team does instead, which is more than they first expected and less than they once feared.
The answer they first gave was fashionable. Automate everything, rent everything, keep no one around to mind the machinery — the destination tech people call NoOps, meaning operations so thoroughly automated that no dedicated team is needed. Their journey toward that word, and what it turned out to mean, is a friendlier and more useful story than most of the keynote versions. It might save your team a bad quarter.
Act One: The NoOps Dream
Karo put it memorably in a team chat: “I want to fix visas, not servers.” Who wouldn’t? Managed platforms promised a world where deployments were push-button, scaling was automatic, and nobody carried a pager. The version of the dream they had absorbed said operations could be bought and automated until it simply stopped existing as a job. What they eventually learned — partly from this plain NoOps primer, partly from a fortnight they do not fondly remember — is that the work does not vanish when you stop hiring for it. It relocates, quietly, into places you forgot to look: the provider’s settings panels, the automation scripts, and the developers’ own evenings.
Act Two: The Wake-Up Call They Saw Coming
Their first serverless architecture felt perfect: appointment reminders, document-status checks, a payment hook — small functions, no servers, no sysadmins. For months it genuinely was pleasant. Deploys took minutes, the dashboard stayed green, and the founders spent their time on the product instead of the plumbing, which had been the entire point. Then two things happened in the same week. A partner integration triggered a retry storm that ran up a bill nobody had approved, and Devan read an engineering writeup from Amazon’s own Prime Video team that he has retold at every meetup since.
That team had built a monitoring service out of serverless building blocks — Step Functions and Lambda — and watched it collapse under roughly five percent of the load it was designed for. Their fix was almost embarrassing: they rebuilt the service on ordinary containers on EC2 and cut running costs by about ninety percent. The moral was not that serverless is bad. It was that the building block has to fit the workload, and no amount of automation changes that.
“We’re not Prime Video,” Devan said, “but our reminder bursts and our document processing don’t have the same shape either.” That sentence — workloads have shapes — became the team’s new planning tool.
Act Three: What They Actually Changed
The refit was less dramatic than the original dream, and it stuck. The reminder traffic, spiky and light, stayed on managed serverless functions, where it is genuinely cheap and genuinely hands-off. The batch document processing, long-running and steady, moved to a small reserved setup that costs less per month than the functions had during one bad retry storm. The Saturday-morning deploy script that only Karo understood got documented, then automated, then given a second reader — because automation nobody else can inspect is just a secret with extra steps.
Their checklist, distilled from the whole episode, is short enough to steal:
- Match the building block to the workload’s shape before admiring its features.
- Keep standard, bursty things managed; keep steady, heavy things reserved.
- Treat every automation as a team member — reviewed, documented, replaceable.
- Decide in advance who reads the bill, because something always reads it last otherwise.
Halfway through the refit they also accepted what they had been resisting: one contractor, two days a week, doing the cloud-reliability work nobody on a five-person team does well between features. Finding her took less time than they feared, largely because they had stopped shopping by brand and started shopping by need, the approach a guide to software discovery platforms recommends for exactly this kind of decision. Teams further along that path than Karo and Devan describe the same relief — it is the reason services built around professional DevOps support for cloud reliability exist at all. Low-ops, it turns out, is a staffing ratio, not a purity test.
Act Four: The Exit Nobody Priced
One more lesson arrived by way of a news alert rather than an outage. Karo, researching their provider’s lock-in, found that switching costs have long been the quiet moat of cloud platforms — until the EU Data Act begins abolishing egress charges for cloud exits on 12 January 2027. Her first reaction was delight. Her second, after an afternoon with a spreadsheet, was more sober: the regulation removes the transfer fee, but nobody can repeal the engineering effort of actually moving a live product. Their exit plan now exists, costs an estimated six weeks of one engineer’s time, and sits in the same folder as their backup drills — reviewed twice a year, which is twice more often than most startups review anything that cannot send an invoice. “It’s like permanent residency,” she said, in a metaphor her co-founder approved of instantly. “You hope you never need the paperwork — but you know exactly where it is.” Readers who have prepared an application of that kind will recognise the feeling from checking eligibility before applying: the preparation is the confidence.
Act Five: Where the NoOps Story Lands
Three years in, Karo and Devan’s service runs with no operations department, exactly as the original dream promised. It also runs with a duty register, a named owner for every recurring task, rehearsed recoveries, a priced exit, and a part-time human whose whole job is noticing problems early. That is the honest version of the destination: fewer operational duties than a traditional setup, each one accounted for, none of them anonymous.
The word NoOps survives on their slides, but its meaning has changed. It no longer means “nobody does operations.” It means “nobody does operations without knowing about it.” When a new hire asks why the duty register exists or why the exit folder is reviewed, the answer they get is short: because the opposite of ops is not no-ops, it is unowned ops. For a small team anywhere — visas, travel, retail, anything — that distinction is the difference between a slogan and a system. Pick your building blocks to fit the workload, keep the exits priced, let a professional eye glance over the horizon occasionally, and the robots can mind the rest. Mostly. On a good day. With the paperwork in order — which, for a team born in the visa world, was always the family motto anyway.
