After SaaS: How AI Could Rebuild Indian IT Services

The standard story about AI and Indian IT is a story of subtraction: fewer developers, smaller outsourcing contracts, and automated work. Sidu Ponnappa offers a more demanding—and ultimately more interesting—account. AI does threaten the labor-arbitrage machine. But it also lowers the cost of producing useful software so radically that a much larger field of previously uneconomic problems can be attacked. The opportunity is not to preserve the old service model with a chatbot attached. It is to rebuild the model around rapid proof, operational outcomes, domain knowledge, and unusually capable people.

That thesis begins with a counterintuitive claim about SaaS. Software-as-a-service was never valuable merely because software lived in a browser or arrived by subscription. It won because it resolved three economic risks that once made enterprise software painfully difficult to own. AI and standardized cloud infrastructure are now resolving the same risks by another route. Once that happens, the compromise at the center of SaaS—many customers adapting themselves to one generalized product—becomes negotiable.

SaaS Was an Economic Solution Before It Was a Category

To understand what AI changes, start in the client-server era. A company needing a serious internal system had little choice but to commission one. That required major capital expenditure—often crores of rupees or more—with no guarantee employees would find the result useful. Even after the build, deployment and upgrades had to reach software running inside the customer’s data center. The buyer therefore carried three separate burdens:

1. Capital risk: a large up-front spend to create the system.
2. Product-market-fit risk: usefulness became clear only after much of that capital had already been committed.
3. Distribution risk: every release, update, and installation had to reach customer-controlled infrastructure.

SaaS pooled those risks. A vendor funded the product, learned across customers, and maintained a centrally hosted version. What looks inevitable now was not inevitable in 2005; persuading an enterprise to put email or business data in a cloud application could sound absurd. The model took roughly a decade to mature because its adoption depended on infrastructure, security expectations, and institutional habits catching up.

This history also explains the divergence between “big tech” and everyone else. Amazon treated technology as core to retail; Uber treated it as core to transportation. Most Fortune 500 businesses chose differently: they transferred software risk to vendors so they could focus on logistics, healthcare, banking, or manufacturing. That choice was rational when bespoke software was expensive, slow, and likely to fail.

AI and Cloud Attack All Three Risks at Once

Cloud standardization has largely neutralized distribution. A service provider can run software in its own cloud or inside a customer’s cloud account without returning to the old world of bespoke on-premise installation. AI then compresses development cycles. An expensive expert remains expensive, but that expert may generate 10 or even 100 times the output. More importantly, the team can make smaller bets and learn before committing the full budget.

Consider the concrete example of a performance-review system for a company with tens of thousands of employees. The old choice was between buying an HRMS module and undertaking a long custom project. The bought module was politically safe even if employees quietly continued the real process in email and spreadsheets. A custom build might take a year before anyone discovered that it had the same adoption problem.

With an AI-native delivery loop, a small team can build a basic version in two weeks, test it with real users, revise it for another two weeks, and expand only when behavior confirms value. Rollout can advance through cohorts of 1,000, 2,000, and 5,000 employees rather than through a one-time enterprise launch. The critical change is not merely cheaper code. It is cheaper evidence.

When the cost of a wrong answer falls, an enterprise no longer has to buy the safest generalized answer.

At mid-market and enterprise scale, this creates a credible alternative to seat-based SaaS pricing: a tailored system plus a flat annual maintenance contract. Small companies may still find standardized SaaS more efficient. But larger buyers can increasingly ask why they should contort their process around features and workflows they do not need when software can be shaped around them at a similar—or eventually lower—total cost of ownership.

The Product Does Not Disappear. Its Center of Gravity Moves

The strongest objection is that product companies do more than implement stated requirements. They aggregate learning across hundreds of customers, anticipate needs, and ship innovation any single buyer would not request. A custom shop, by contrast, risks becoming an order taker.

The answer is a new definition of productization. Under the SaaS model, customer learning is embodied in a centralized software architecture. Under the emerging model, it can be embodied in a centralized knowledge base: domain research, procedures, compliance interpretations, operational playbooks, evaluation criteria, and patterns derived from repeated engagements. AI makes that knowledge cheap to retrieve and apply even when each customer runs a different architecture.

This is Ponnappa’s sharpest formulation: “Software has gone from asset to inventory.” The reusable asset is no longer necessarily the code shared by 1,000 customers. It is the knowledge used to produce and evolve fit-for-purpose code for each one. The common architecture can even become a liability: mature HRMS, CRM, and ERP products grow unbearably complex precisely because one structure must support every segment, exception, and historical workflow.

Compliance does not invalidate the model. A specialized provider can maintain regulatory expertise across the United States, Singapore, or Australia and propagate what it learns through its knowledge system, then update each implementation. The shared capability survives; only its packaging changes.

From requirements to operational metrics

A more profound shift follows. Traditional enterprise projects begin with a business outcome, translate it into a long requirements document, and then lose the outcome inside one-to-three-year delivery road maps. Consumer companies operate differently: they live and die by daily operational metrics, release frequently, and watch whether behavior changes.

An AI-native service company should therefore stop selling “software” and sell a measurable operational movement. It should identify the manager who owns a number, form hypotheses about how software could move it, and iterate until it does. Adoption is not a customer-success cleanup exercise after the sale. It is part of delivery from the first two-week production release.

The practical filter is strict: pursue work where the team can move the responsible manager’s KPI directly, without requiring ten other departments, a new corporate strategy, or a six-month transformation program. That constraint makes proof possible.

The Two-Week Contract Reverses Services Incentives

Traditional IT services matured into a commodity market differentiated by cost, convenience, and brand. Ponnappa cites the industry’s familiar claim that 80–90% of software projects fail or disappoint. When results take two or three years to evaluate, buyers retreat toward brand and vendors maximize the size of the initial order. Both sides know the project may become a “dumpster fire,” but the feedback arrives too late to discipline the sale.

AI compresses time-to-value from years toward weeks. That permits a radically different commercial offer: isolate one meaningful problem, contract for two weeks, put something into production, and test it. In Ponnappa’s formulation: “I will prove my value to you in two weeks. If I can’t do this, don’t pay me.” The engagement may still contain what used to be months of work; it is small only in AI-era time.

This flips the vendor’s incentive. Rather than front-loading scope because failure will surface much later, the provider refuses the large order until value is visible. If the buyer can see that every $1 spent creates $2 of operational gain, expansion becomes a consequence of evidence rather than procurement theater. Proof of value becomes the commercial core.

Indian IT’s Opportunity Requires Better Talent, Not Cheaper Talent

The old Indian services advantage was a large supply of lower-cost technical labor. The new one, if it can be built, is a large supply of high-agency domain operators amplified by AI. These are not the same workforce under a new training certificate.

AI is high-friction work. It may make a capable person 10 times more productive while demanding, in Ponnappa’s estimate, at least twice the cognitive effort. People who spent years below their cognitive limit report finishing the day physically exhausted because they have pushed their minds continuously. One operator may be directing two agents at peak, sometimes three, with each requiring precise context, review, correction, and delegation every few minutes.

That dynamic suggests a barbell outcome. Headcount can shrink even as compensation for the best operators rises. Ponnappa sketches a possible Indian market in which ₹1–3 crore roles expand for a smaller group, replacing some of the millions of ₹lakh-level jobs supported by labor arbitrage. Yet demand need not collapse. Every enterprise still has “1,000 Excel sheets” whose workflows were never worth turning into applications. As production costs fall, that backlog becomes addressable.

India can serve this demand because it has technical people, English-language access to global customers, and a vast position inside existing enterprise operations. But cultural optimization for certainty may be a disadvantage. The emerging market rewards curiosity, skeptical thinking, risk tolerance, and the willingness to revise beliefs—not only exam rank and execution along a known path.

“It is not a reskilling problem.” The scarce input is not familiarity with a tool; it is the capability and discipline to think clearly through it.

A six-month course cannot manufacture judgment. Anyone can ask a model a question; the model may enthusiastically validate nonsense. The operator must frame the problem, structure delegation, inspect details, reject flattery, and recognize when the output violates domain reality. Leaders are no exception. In fact, executives who have not worked at high detail for years may find the transition especially difficult.

The Engineer Must Either Touch Grass—or Advance the Frontier

The services engineer of the future resembles an engineer inside a consumer-facing logistics, retail, or delivery company. That person joins support calls, spends time with call-center staff, watches field operations, speaks to users, and understands the business number the software is supposed to change. Requirements cannot simply be handed over a wall to someone who builds in isolation.

There remains an important place for the serious hacker who does not want customer meetings. India’s services industry sits on an extraordinary stream of operational and software-delivery data generated across billions of dollars of projects. Much of it is not captured, and legal constraints will govern what can be used. But if firms can preserve and responsibly learn from the permissible portions, that data could support the next generation of models for the software development lifecycle. Frontier work needs engineers who want to sit in a room, focus deeply, and improve the model itself.

What disappears is the comfortable middle: the engineer who neither understands operations nor pushes technical capability, but expects a fixed requirement and a quiet corner. In an AI-native organization, “developer,” “business analyst,” and “product manager” become less useful identities. The job is to be a domain expert in the operational workflow of excellent work—and to make an agent produce an artifact as good or better in a fraction of the time.

The apprenticeship problem

Fresh graduates face a structural bind. They lack the tacit process knowledge required to judge excellent output, but a senior engineer using AI may be an order of magnitude more productive than one slowed down to train a junior. Building trusted operational discipline may take about 12 months in some fields and closer to 18 months in software. Worse, AI compounds both excellence and sloppiness: an undisciplined developer can create a year’s worth of mistakes in two to four weeks because a year’s worth of work now fits into that span.

One practical workaround is unusually specific: choose a substantial open-source project known for engineering discipline and contribute manually and consistently for six to 12 months. Study where maintainers discuss decisions and how much of that discussion concerns quality. The objective is not to reject AI forever; it is to develop enough craft to know what should be delegated and what “good” looks like. Separately, an experienced professional trying to make the transition can impose a daily constraint: spend four hours doing real work through AI for six months. The time requirement forces an actual workflow change instead of reducing AI to a replacement for Google.

India Is Not Defending Third Place; It Is Choosing What Third Place Means

The strategic conclusion is more ambitious than saving outsourcing jobs. India is behind the United States and China in frontier AI, but being number three is not failure. Indian IT firms possess cash flow, customers, talent, and access to operational knowledge. Collectively, the top listed firms could plausibly finance hundreds of millions of dollars of frontier research each quarter. They could make $50 million offers to leading Indian researchers abroad. The constraint is not the theoretical availability of resources but the will to redirect them.

The next five to ten years could preserve a strong number-three position and perhaps create a path toward number two on selected axes. That outcome requires incumbents to stop treating AI as an efficiency layer on the existing pyramid. They must capture knowledge, redesign incentives around proof, build high-agency talent, invest in models, and accept that adaptation cycles may shrink from years to months.

The optimistic case is therefore conditional. India can lose millions of routine jobs and still create a more valuable industry—but the transition will be painful, uneven, and not guaranteed. The opportunity exists because software demand is elastic: when applications cost less to build and validate, more business processes become worth software. Winning that opportunity means serving the new demand with a fundamentally different production system.