For ten years I had the job title that gets left out of the founding-team mythology. Not the engineer, not the designer, not the visionary CEO. The ops guy.
I’m 36, in Bengaluru, and I now build production SaaS completely solo — a hotel management platform with 245+ API routes and 180+ database migrations, written largely by AI agents I direct. For a long time I framed my ops decade as the detour before the real thing. I was wrong. It was the training. I just couldn’t see it until the tools changed.
This is the story, and the argument underneath it: the skills that make a good operations person are almost exactly the skills that make a good solo founder in the AI era. Possibly more so than engineering.
Ten Years in the Engine Room
The short version of the decade, because the specifics matter to the argument.
WeavedIn was my first real startup seat — a POS SaaS that I joined when it had 4 customer accounts. I was there as it grew to 2,500 accounts, doing everything that wasn’t code: onboarding, support, process, the unglamorous machinery of growth. Paytm acquired it.
Paytm put a zero or three on everything. I worked on India’s first online EDC (card machine) deployment, in a business line doing ₹96 Cr in revenue. At that scale you stop believing in heroics and start believing in process, because heroics don’t survive contact with lakhs of merchants.
UrbanPiper was B2B SaaS onboarding as a discipline — 50+ onboarding projects, each one a mini-implementation: understand the client’s operation, map it to the product, find the gaps, get them live. I got good at the specific skill of translating between how a business actually runs and what software thinks it does.
Aviyel flipped me to the other side of the keyboard: head of global operations for a developer community platform, growing a community from zero to 2,000+ members and coordinating 200+ technical writers. Years of working around developers became years of working with them daily.
Then independent consulting — ED Consultation, deliberately capped at 3 clients — which taught me what nothing else had: what my judgment was worth when it wasn’t wrapped in an employer’s brand.
At no point in those ten years did I ship production code. That fact used to feel like a ceiling.
The Ceiling That Dissolved
The standard path for someone like me was to found a company by finding “a technical co-founder” — pitching engineers on weekends, trading half the company for the ability to build.
What changed wasn’t me learning to code in the traditional sense. It was AI coding agents crossing the line from autocomplete to something like a tireless dev team that reads your whole codebase and follows written instructions. The bottleneck moved. Building software stopped being constrained by who can write the code and became constrained by who knows exactly what the code should do and how to verify it did it.
Read that sentence again, because it’s the hinge of this whole essay. Specifying precisely. Verifying independently. That’s not an engineering skill set. That’s an operations skill set.
So I started building Dszape — “Shopify for hotels” — solo. The full how is in how I build SaaS solo with AI, and the stack is in the solo founder AI stack. Here I want to make the less obvious argument: skill by skill, the ops decade maps directly onto this new job.
SOPs Became Agent Instructions
An SOP is a document that lets a process run correctly without you standing next to it. I wrote hundreds of them across WeavedIn, Paytm and UrbanPiper, and I learned the hard truths: nobody follows an ambiguous SOP, nobody follows a bloated one, and an SOP that isn’t enforced by the system eventually gets ignored by everyone.
Every one of those truths transferred, word for word, to working with AI agents.
My repository carries a written rulebook that agents read before touching code — rules like “never ignore a database error”, “financial operations must fail loudly, never silently”, “certain tables may only be written through one canonical function”. Each rule exists because something real broke. Each is written the way a good SOP is written: the rule, the incident behind it, the exact right and wrong examples.
And, crucially, the rules are enforced by the system, not by hope — lint checks that block bad patterns, database triggers that reject illegal writes, tests that walk the flows. That instinct came straight from ops: a process that relies on everyone remembering is a process that’s already failing. I wrote that up years before I could build software: how to build SOPs that people actually follow. It turned out to be a post about prompt engineering. I just didn’t know it yet.
Onboarding Projects Became Product Specification
Those 50+ UrbanPiper onboarding projects were each an exercise in the same translation: sit with a business, understand how it actually operates (never how the sales deck said it does), and map that to software without breaking either.
That translation is now my core product skill. When I spec a feature for Dszape, I don’t say “build a checkout flow”. I say: a folio must settle to zero before checkout; a corporate guest splits the bill between company and personal charges; a walk-in guest has no prior booking, so the folio is created at check-in, never before. The AI writes the code. The spec — the encoded understanding of how a hotel front desk actually runs at 11 PM — is the part no model can supply.
Years of watching software fail real operators is exactly what tells you what the software must do.
RCA Became My Quality System
Operations people live in root cause analysis. Something breaks at scale, you ask why five times, you fix the cause and not the symptom, and you change the system so that class of failure can’t recur. I’ve written a whole series on it, starting with the power of root cause analysis in startups.
Building solo, RCA became my entire quality culture. When a silently-dropped database error bounced every signed-in user back to onboarding, the fix wasn’t just the patch — it was a permanent rule, a lint check, and a test, so that shape of bug is structurally harder to write. When billing showed ₹0 for weeks because a type cast hid missing database columns, same treatment. Every incident becomes a rule; every rule becomes automation. Three layers deep, because any single layer gets bypassed. The full system is in vibe coding in production: guardrails that actually work.
An engineer might call this defensive engineering. I call it what ops always called it: making sure the same fire can’t start twice.
Metrics Discipline Became Independent Verification
The ops reflex I trust most: never accept a status report you can’t verify against the source system. At Paytm scale, “the deployment went fine” meant nothing until the dashboard agreed.
AI agents made this reflex existential. An agent will confidently report a feature as done when what it means is “the code compiles”. I learned to grade claims into separate buckets — actually verified against the running system versus merely reported — and eventually built that grading into BeckyOS, my multi-agent coding system, as a dedicated verifier agent. The principle came straight from ops: the agent that builds can’t grade its own work, the same way a sales team doesn’t audit its own numbers. That story is in lessons from building a multi-agent AI coding system.
Why Operators May Be Better Positioned Than Engineers
Here’s the spicy claim, made carefully.
When code was the bottleneck, engineers held the leverage, rightly. But AI has made code abundant, and when something becomes abundant, the leverage moves to whatever is still scarce. What’s scarce now:
Knowing what to build. Domain understanding earned by watching an industry operate — the kind I detailed in the vertical SaaS post — doesn’t come from the model. It comes from the years.
Specifying without ambiguity. The daily craft of ops — SOPs, runbooks, escalation matrices — is precisely the craft of instructing agents.
Verifying independently. QA discipline, metrics scepticism, “show me in the source system”. Operators are professionally paranoid in exactly the way agent-directed development requires.
Managing a team you don’t fully control. An ops manager coordinates people with their own habits and failure modes. Directing a fleet of AI agents feels far more like that than like programming.
To be fair to engineers: deep technical judgment still matters enormously, and the best engineers are also excellent at all four of the above. My claim isn’t that operators beat engineers. It’s that the gap has inverted for founding specifically — a domain-expert operator with AI agents can now ship what used to need a funded team, while a brilliant engineer with no domain depth ships a beautifully-built product nobody asked for.
The decade in the engine room wasn’t the detour. Writing code was never the job. Knowing what must be true, and proving it is — that was always the job. The tools finally caught up to the job description.
FAQ
Can a non-engineer really build production SaaS with AI in 2026?
Yes — I’m doing it, with a platform at 719+ source files and real hotel money flowing through it. But “non-engineer” doesn’t mean “non-technical”: you still need to reason about data models, review what agents produce, and verify behaviour ruthlessly. The skill floor moved; it didn’t disappear.
Which operations skill transfers most directly to building with AI agents?
Writing SOPs. An agent rulebook is an SOP with a compiler. If you can write a process document that a distracted new hire follows correctly, you can write instructions an AI follows correctly — and you already know unenforced rules get ignored.
Should ops people learn to code before attempting this?
Learn to read code and to reason about systems, yes. Grinding through syntax mastery first, no — you’ll get more return from sharpening specification, RCA and verification, then letting the agents handle syntax while you check their work.
Isn’t this just “ideas guy with extra steps”?
The opposite. The ideas-guy failure mode is having a vision and no ability to execute or verify. The operator’s whole trade is execution and verification — what was missing was code, and code is the part AI now supplies.
I write about this transition in public — the incidents, the costs, and what the ops decade keeps teaching me. More on the about page.
