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 now build Dszape, a hotel-management product, as a solo founder using AI-assisted development. 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: operations taught me how to specify work, observe failure and verify completion. Those skills now shape how I build.
This is a bounded first-person recollection, not an audited history of my former employers or a customer-outcome report. I removed company account totals, revenue attribution, “first in India” claims, client counts, codebase counts and incident scope that do not share one safely publishable evidence package. The role sequence and lessons are my account of my own work. They do not claim that I caused a former employer’s growth.
I now separate career evidence into three levels. A public product or registry can establish that something exists. A dated internal record can support a private review without becoming safe to publish. A personal recollection can explain what I learned, but it must be labelled as recollection and should not quietly turn into a company metric. When those levels conflict, I keep the narrower claim. That makes the story less theatrical and more defensible.
The point of this essay is therefore not that my former employers prove I can build software. It is that repeated operating practices shaped the way I approach specification, handoffs, failure and verification today.
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, an early POS SaaS where my work included onboarding, support and process. It taught me how quickly an unclear handoff becomes a customer problem.
Paytm changed the operating context. I worked on merchant onboarding and payment-device dispatch. Larger queues and more dependencies made process, reconciliation and escalation more important than individual heroics.
UrbanPiper made B2B SaaS onboarding a discipline for me. Each implementation required understanding the client’s operation, mapping it to the product, finding gaps and coordinating a safe launch. I got good at translating between how a business actually runs and what software thinks it does.
Aviyel moved me closer to product and developer work as head of global operations for a developer-community platform. Years of working around developers became years of working with them daily.
Then came independent consulting, which forced me to explain my judgment without an employer’s brand wrapped around it.
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. Tools such as Claude Code made it practical for me to direct more implementation work through written instructions and repository context. Vendor documentation establishes the tool’s public capabilities. It does not prove my configuration, code quality or product outcomes.
The bottleneck moved for my own work. I still needed to know what the software should do and how I would verify 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 intended to let a process run correctly without you standing next to it. Across my operations roles I learned the hard truths: ambiguous instructions create interpretation, bloated instructions hide the decision, and unenforced rules are easy to ignore.
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
My UrbanPiper onboarding work repeatedly exercised the same translation: sit with a business, understand how it actually operates, 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 quality culture. I have encountered failures where a database error was treated like an empty result, and where a type cast concealed a mismatch between code and database shape. These are bounded recollections from my own build, not audited customer-impact statements. The useful part is what changed: error handling became explicit, unsafe patterns became lint targets, and the journey gained regression coverage. The full method is in vibe coding in production: guardrails that actually work.
Google’s SRE postmortem guidance reinforces the discipline I care about: learn without reducing a system failure to one person’s action, then track corrective work. My version is simple. A lesson is not complete until it changes a control and that control can be tested.
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 is never accepting a status report I cannot verify against the source system. “The deployment went fine” is not the same as a reconciled result.
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 is not that operators beat engineers. It is narrower: AI-assisted building gave my operations background a direct route into implementation, while making technical review and honest verification more important, not less.
The decade in the engine room wasn’t the detour. Knowing what must be true, and proving it is, was always the job. The tools finally gave me another place to apply it.
Download the operator-to-builder evidence map
I turned the transfer into a reusable review template:
Download the operator-to-builder evidence map
The map asks you to connect an operations skill to a specific building practice, evidence source, boundary and next test. It contains no invented employer result or completed self-assessment. Every personal evidence field is marked REPLACE.
My public proof is deliberately narrower than the full private build. The Dszape public site establishes the product’s public positioning. The BeckyOS npm page establishes a public package and version history. Neither proves private tenants, customer outcomes, every feature or the quality of every release.
FAQ
Can a non-engineer really build production SaaS with AI in 2026?
I am doing it, but this article does not claim audited customer outcomes or use a changing file count as proof. “Non-engineer” does not mean “non-technical”: I still need to reason about data models, review what agents produce and verify runtime behaviour. The skill floor moved for me; it did not 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.
