Why I Still Write Code Every Weekend as CEO of a 700-Person IT Firm
Why IndiaNIC's CEO still spends weekends building and breaking things in Claude Code and n8n — and why every tech leader needs to feel the gap between a slick AI prototype and production-grade software before pricing it into a client promise.
It's past eleven on a Saturday night, my kids are asleep, and I'm hunched over a laptop arguing with a failing n8n webhook instead of finishing the film my wife picked. Anyone running a services company at scale will recognize this exact trade: ten more minutes at the terminal now, or finding out on Monday from an account manager that a promise I made to a client doesn't actually work the way I described it. I take the ten minutes, almost every weekend, and that single habit is why I still trust my own judgment about what IndiaNIC can deliver.
I've spent 25 years building IndiaNIC into a 700-person software and IT services company, across gaming, gadgets, and now agentic AI. Somewhere around year fifteen, most CEOs I know made a quiet trade: they stopped writing code and started reading about it in slide decks. I made a different bet in 2026, and this piece is about why that bet is paying off harder now than at any point in my career, because the tools changed faster than the advice about how to lead them.

The CEO Who Hasn't Touched Code in Five Years Is Guessing, Not Leading
Every quarter, someone on my leadership team hands me a roadmap built on a demo that took an engineer roughly 45 minutes to put together in Claude Code, out of a project we'll likely bill at 400 to 600 engineering hours once it's production-ready. The demo works. It almost always works. The question that decides whether we win or lose a client isn't whether the demo works, it's whether the six weeks of production hardening behind it were priced in, and that's a judgment call I can only make honestly if I've spent enough Saturdays fighting the same tool myself.
What Happens When Strategy Outruns Practice
The failure mode I've watched other founders walk into isn't laziness, it's distance. They read the same analyst notes I do, sit through the same vendor pitches, and nod along when someone says agentic workflows will cut delivery time in half. Then they set a client timeline based on that number, and three months later they're explaining a 30-40% overrun to a board that trusted the number because a CEO said it out loud. A number you've never tested yourself isn't a strategy. It's a rumor with a title attached to it.
Why "Hire Smart People and Get Out of Their Way" Breaks Down With AI Tools
For twenty years that advice was mostly right, and I gave it to younger founders without hesitation. Delegate the technical depth, trust your engineers, spend your time on people and capital allocation. It worked when the tools your team used changed every few years and a good engineering leader could brief you accurately on what was possible. It stops working when the tools change every few months, and the gap between "the model can do this" and "we can ship this safely" becomes the entire ballgame.
The Report That Looked Fine Until I Opened Claude Code Myself
Eighteen months ago, a delivery lead brought me a proposal to cut a client's data-migration timeline by sixty percent using an agentic pipeline built in n8n, chained to a coding agent for the transformation scripts. On paper it was clean, three stages, neatly diagrammed. I blocked out a Saturday, rebuilt the same pipeline myself against a copy of the client's schema, and hit the wall the demo had quietly skipped past: the agent handled clean records beautifully and fell apart on the exact malformed rows that made up roughly eleven percent of this client's actual data. We had already sent the sixty percent estimate to the client that week, before I ran my own version. That is the one deadline I regret setting, because I set it from a slide instead of from a terminal, and it's the reason I no longer sign off on a timeline I haven't tested with my own hands.
Vibe Coding Isn't a Junior Skill Anymore
Vibe coding, prompting an AI agent to generate working software from a natural-language description, used to be something you handed to a junior developer to save time on boilerplate. That framing is out of date. The same prompt-driven fluency that lets a junior engineer scaffold a feature in an afternoon is exactly what a CEO needs to evaluate whether a six-figure proposal is realistic, because the proposal and the prototype are increasingly built with the same tools, by people with the same blind spots.
My Weekend Framework: Build, Break, Then Decide
What Is Vibe Coding?
Vibe coding is the practice of directing an AI coding agent, such as Claude Code, through natural-language prompts to generate, modify, and run software, with the developer guiding intent and reviewing output rather than writing every line by hand. It compresses the distance between an idea and a working prototype from days to hours.
My framework for staying grounded has three parts, and none of them are complicated. First, I build one small real thing every weekend, not a toy, something that touches an actual workflow at IndiaNIC. Second, I break it on purpose, feeding it the messy inputs a client's production data would actually contain, not the clean sample data a vendor demo always uses. Third, I don't let a number reach a client proposal until I've personally hit that failure point myself, or someone I trust has confirmed they have.
Where the Framework Paid Off: Three Examples From IndiaNIC
This isn't theoretical. Two specific decisions this year came out of a Saturday, not a status meeting.
| The expensive mistake: Founders sign off on AI-driven delivery timelines based on a demo built by someone who never had to make it work on the client's actual, messy data. Test the failure case yourself before you let it into a contract. |
An account team wanted to pitch a fully autonomous support-ticket triage system built on n8n with an agentic layer on top of it. I ran it against a batch of 1,240 of our own real support tickets from the prior three months, over a weekend, before we pitched it. It routed the sample correctly close to 96% of the time, a number I was comfortable presenting, but it made two confidently wrong escalation calls in that same batch, the kind that would have been serious in a live support queue. We pitched a hybrid model instead, agent-drafted with human sign-off on escalations, and won the deal anyway, because we could speak to the failure mode instead of pretending it didn't exist.
| A prototype tells you what's possible. Only production tells you what's true. |
None of this means every CEO needs to ship production code personally, forever. It means every CEO setting technical strategy needs enough hands-on exposure to smell the difference between a demo and a deliverable, because that difference is exactly where services businesses either protect their margin or quietly bleed it out on rework.
Why Does the Gap Between Prototype and Production Matter?
The gap between prototype and production matters because a working AI-generated demo only proves a tool can succeed once, on clean data, in a controlled setting, while production software must succeed repeatedly, on messy real-world inputs, under monitoring, security, and cost constraints a demo never faces.
| So here's the question I'd put to any founder or CTO reading this: when did you last personally hit the failure case in a tool your team is proposing to a client, instead of trusting someone else's slide about it? |
Block out two hours this weekend. Open whatever agentic tool your team is pitching to clients, and try to break it on your own messiest data before your Monday meeting. Bring what you find back to your leadership team instead of the demo reel, and tell me in the comments what broke first.
Frequently asked questions
Do CEOs really need to code themselves?
Not every CEO needs to write production code, but any CEO setting technical strategy or client timelines needs enough hands-on time with the actual tools, such as Claude Code or n8n, to judge the gap between a working demo and a shippable product, rather than relying entirely on secondhand reports.
What is vibe coding?
Vibe coding is directing an AI coding agent through natural-language prompts to generate, modify, and run software, with a human guiding intent and reviewing the output instead of writing every line manually, dramatically shortening the time between an idea and a working prototype.
What's the difference between an AI-generated prototype and production-grade software?
A prototype demonstrates that a task can succeed once under clean, controlled conditions, while production-grade software must succeed consistently across messy real-world data, at scale, with security, monitoring, and cost controls in place, a bar most weekend demos never have to clear.