AI-Native IT Services: Sidu Ponnappa’s Case for Rebuilding Indian Software Delivery

The old Indian IT services model was built around headcount, long contracts, slow delivery, and predictable escalation management. Sidu Ponnappa argues that AI does not merely automate parts of that machine; it changes the delivery unit itself.

Source: Mundhe Banni Podcast, Sidu Ponnappa, “Everyone's Wrong About AI Killing IT Jobs. Here's What Actually Happens,” Episode 24 · Video ID 0zt7iP03x0w · Kannada conversation with English subtitles · Watch on YouTube.

Language note: This article is written in English from the available English subtitle track for a Kannada episode, with Kannada-context references preserved where relevant.

Who Is Sidu Ponnappa?

Sidu Ponnappa is an engineer and entrepreneur from Kodagu who has lived several versions of the Indian software story: Thoughtworks, an early SMS-era startup called ActiveMob, the services company C42 Engineering, the developer education product RubyMonk, and later engineering leadership at Gojek as the Indonesian company scaled into a decacorn. He is now building RealFast AI around what he calls AI-native IT services.

His credibility comes from having seen both sides of the industry. He has built products, run services, watched markets explode, and seen the cost of scaling from the inside. That makes his argument harder to dismiss as either AI hype or outsourcing pessimism.

The Central Shift: From Big-Bang Delivery to Daily Delivery

Traditional IT services are slow because the operating model is slow. The customer signs a large contract, the vendor staffs a team, requirements move through business analysts and project managers, engineering work begins, escalations pile up, and business impact often arrives after six months, one year, or two years. Sidu reduces the industry’s lived reality to a blunt line: IT services means escalations.

AI-native delivery changes the expected cycle time. The problem being solved may remain the same, but the way work is decomposed, implemented, reviewed, and shipped has to be compressed. A scope that previously justified a one- or two-year engagement has to be attacked in days and weeks. The customer should not wait years to learn whether the software mattered.

“The ‘what’ is not changing. The problem is the same. The ‘how’ is changing.”

That distinction matters. AI does not remove business problems. Customers will still need application maintenance, testing, workflow automation, integrations, migrations, and bespoke internal tools. What changes is the unit economics of serving those needs. One strong engineer, or one strong pair, can now do work that previously required a larger team. The leverage moves away from compliant execution and toward people who can keep redesigning the delivery process itself.

Industrializing IT Services Without Preserving the Factory

Sidu compares the change to the industrialization of manufacturing. Before assembly lines, production was artisanal and slow. After assembly lines, repeatability and throughput changed the economics of entire categories. Indian IT services already had process, but it was a headcount process: SOPs from the top, regular cycle times, predictable staffing pyramids, and median billing rates that reflected labor arbitrage.

AI-native services require a different kind of industrialization. The repeatable unit is not merely “developer follows ticket.” It is a system where problem decomposition, code generation, review, test creation, deployment, documentation, and maintenance are continuously reworked around model capability. The people who own that evolution become far more valuable than people who simply comply with last year’s process.

This is why Sidu does not frame AI as a simple job-killer. Commodity work gets automated first. Application maintenance, repetitive testing, boilerplate implementation, and low-judgment coding are vulnerable. But the higher-value work moves toward engineers, PMs, BAs, and leaders who can ask: how do we serve 20 customers with a structure that used to serve 10?

Jevons Paradox: Cheap Software Can Create More Software Demand

The fear narrative assumes a fixed amount of software demand. If AI makes code cheaper, fewer people are needed. Sidu’s counter-thesis is closer to Jevons Paradox: when a resource becomes cheaper and easier to use, total consumption can rise dramatically.

If custom software becomes cheap, fast, and reliable enough, businesses will build systems they previously could not justify. Smaller markets, local workflows, niche communities, departmental tools, and internal automations become economically viable. The barrier to entry falls, which is both opportunity and threat. Many more products can be created, but revenue pools may cap out sooner because competitors can copy patterns quickly.

That creates the “millionaire startup” era. Not every software company needs to chase the old venture-backed billionaire outcome. A founder can build for a narrower customer set, generate meaningful profit, and avoid the pressure to become a global category monopoly. The downside is that defensibility becomes harder. The upside is that more builders can play.

Why Tool Licenses Alone Do Not Create Velocity

Many companies have given engineers Copilot, Cursor, Codeium, Claude, or ChatGPT and then wondered why velocity did not transform. Sidu’s answer is simple: the leader is not AI-native.

A manager cannot just buy licenses and wait for the org chart to become faster. Leadership taste, domain expertise, and judgment have to be injected into the new process. If senior people do not use the tools themselves, they cannot redesign reviews, acceptance criteria, quality gates, estimation, staffing, customer communication, or incentives. The operating model remains pre-AI, with AI sprinkled on top.

Sidu’s practical signal: pay for AI tools until the ROI becomes personally obvious. A $20 subscription builds conviction. A $100 subscription forces the user to find real leverage. The point is not the exact model tier; it is the psychological shift from casual experimentation to “this returns more than it costs.”

This is especially relevant in India, where people do not casually spend thousands of rupees a month on software. Once someone is comfortable paying because the work return is clear, they have crossed an important threshold: the tool is no longer a toy.

India’s AI Services Advantage Is Ours to Lose

Sidu splits India’s AI opportunity into two directions. The first is outside-in: transform the servicing model for global customers before those customers route AI-native delivery elsewhere. India has the relationships, the execution context, and decades of organizational knowledge inside Western enterprises. That advantage is real.

But it is not guaranteed. If Indian IT services companies cling to headcount billing while smaller AI-native teams elsewhere deliver faster, cheaper outcomes, India can lose the very work it spent 30 years accumulating. The country could move from being a net exporter of IT services to a net importer of AI tokens.

The second direction is inside-out: build state-of-the-art model capability and own more of the stack. Sidu is sober here. Chips are not a near-term Indian play. Frontier models require extraordinary capital—he mentions spending at the scale of a billion dollars a quarter—and a research base that China built over decades through universities and frontier papers. India’s realistic path requires serious model strategy, Indic use cases, and reverse brain drain: top Indians in the US coming back to build at home.

Break Every Rule, Especially the Comfortable Ones

Underneath the AI thesis is a personal operating philosophy: break your rules. Not laws, not ethics, but the implicit rules that quietly define what you will not attempt. “I do not travel.” “I avoid public rooms.” “I only eat familiar food.” “I cannot speak in this setting.” Those rules often appear rational only because they protect comfort.

Sidu’s own story starts with rebels. He speaks about C.B. Muthamma, his aunt, the first woman IFS officer, who fought the rules of a system built on the assumption that officers were men and spouses were wives. He describes his mother Kaveri in similar terms. Their example shaped his instinct that each generation’s rebellion will make the previous generation uneasy.

For startups, he offers a mountaineering version of the same idea: the summit is optional, survival is mandatory. ActiveMob failed not because the idea was ridiculous, but because strategy failed and life intervened; he stepped away to care for his mother. Later, C42 and RubyMonk emerged from a more pragmatic financing strategy: use services to self-fund product experiments in a market where Indian seed funding was weak.

Scaling Forces a Moral Reckoning

One of Sidu’s sharpest reflections is that idealism does not scale cleanly. Gojek’s origin story was driver-centric. It was built to help drivers. But when any system reaches massive scale, even a small percentage of harm affects lakhs of people. The “greater good” still contains a “lesser evil,” and that lesser evil becomes large in absolute terms.

This does not lead him to nihilism. It leads him to a harder moral model. Founders need a compass, but they should understand that “amoral” does not always mean “no morals.” It can mean operating from a specific, explicit morality rather than pretending there is a universal purity that survives contact with scale. Anthropic, in his example, draws its own line. The point is to know where your line is before growth, incentives, and competition test it.

Local Culture, Language, and the Psychology of Respect

The conversation ends far from AI but still inside the same worldview. Sidu argues that refusing to learn even minimal local language is incompatible with claiming to care about local culture. He does not demand fluency. His Kannada, he says, is good for an immigrant but not good by native standards. The point is aspiration and respect: wanting to make friends with local people, wanting their admiration because you admire them.

For a builder, that is not a side issue. Products, services, and companies are all cultural systems. If you cannot lower your guard enough to learn how people around you speak, you will struggle to understand how they work, buy, trust, complain, and adopt new tools.

Key Lessons

Why This Matters for Diffie

For Anand and Diffie, Sidu’s argument lands directly on the browser-testing wedge. Frontend teams already feel the old IT-services pain in miniature: long QA loops, flaky handoffs, late bug discovery, repetitive regression work, and escalations that consume engineering attention. Diffie’s opportunity is not simply “AI writes tests.” It is to help teams redesign the delivery unit for frontend quality.

The strongest GTM angle is therefore operational, not tool-centric. Instead of selling only a smarter testing product, Diffie can sell a new operating model: daily visual and browser regression confidence, faster PR review, less manual QA coordination, and a measurable reduction in release anxiety. The buyer should feel the same compression Sidu describes—work that took days of coordination becomes something a small team can run continuously.

This also clarifies ICP. Diffie should prioritize leaders who are already trying to become AI-native but are blocked by frontend-specific quality gates: engineering managers, QA leads, product engineering heads, and founder-led teams shipping UI-heavy products. These buyers understand that Cursor or Copilot alone does not solve the last-mile verification problem. They need a system that injects product taste, domain judgment, and repeatable review into the browser itself.

Finally, the “pay until ROI is obvious” insight is a useful pricing and onboarding principle. Diffie’s activation should get a team to a crisp before/after moment: one regression caught, one release unblocked, one painful manual flow automated, one PR reviewed with browser evidence. Once that ROI is visible, expansion becomes much easier. The goal is not to be another AI tool in the stack. The goal is to become part of the AI-native delivery process.