Shubham Garg has a small correction to make. The question is flattering: how did he build a business with annual recurring revenue of $10 million to $15 million, without external funding, in a couple of years? He interrupts the acceleration. CodeVyasa is in its fifth year, he explains. Four and a half years have passed. Even in a conversation about growth, the calendar deserves a fair hearing.
The moment, in December 2025, offers a useful introduction to the founder and CEO. Garg has built his commercial argument around results that a customer can recognize. A shorter testing cycle. A smaller cloud bill. Software that fits the business using it. That makes time an interesting subject. His company needs enough of it to do the work, while his pitch asks customers to judge what the work achieves.
There is an appealing awkwardness here. Technology services are often purchased through people and hours; better tools can make the same job take fewer of both. A founder selling those tools must decide what, exactly, belongs on the invoice. Garg's answer has shaped CodeVyasa's business and, increasingly, the questions he asks about his own job.
The apprenticeship before the invoice
Before CodeVyasa, Garg worked inside product companies. His career includes Crownit, Haptik and Moglix, with roles spanning growth and product. At Crownit, he worked with Ashish Munjal. These were places where a product had to find users, serve them and keep improving while the business around it changed. They also gave him a network he could later approach as a founder.
His formal training was in electrical engineering at Delhi College of Engineering, where he studied from 2010 to 2014. His college activities included IEEE, Solaris DTU and organizing Engifest. Alongside the technical education came the less tidy business of coordinating people, events and logistics. A festival, like a software release, offers plenty of opportunities for a carefully arranged plan to meet other human beings.
Garg wanted to start a technology company while he was still employed. He eventually tried a supply-chain SaaS venture in 2019, an attempt that did not work out. The business he went on to build would sell engineering services. That change gave his product background a different outlet: solving a customer's particular problem could itself become the business.
He describes the early sales process in practical terms. Call CTOs he knew. Identify a use case. Offer a proof of concept. Win a contract. Personal relationships helped him get a hearing; a working demonstration gave the conversation something firmer to stand on. The first customers were close enough to talk to, and specific enough to teach him what he could sell again.
“I am not a services guy.”
Shubham Garg, December 2025
A bill with a before and after
One engagement with upGrad makes the idea unusually legible. Garg says the education company's annual AWS bill was about $5 million and that CodeVyasa helped reduce cloud costs by more than 40 percent. He describes charging a one-time project fee. The customer would continue to benefit from the savings after the project was finished.
The arithmetic is easy to understand. The harder part is agreeing what the supplier has promised. A customer buying engineering capacity can count people and months. A customer buying a reduction in spending wants a baseline, a target and a result. The conversation moves closer to the customer's operating problem, where a technically busy project can still be an expensive disappointment.
Garg's argument carries a useful discipline: name the improvement before celebrating the activity. Cloud infrastructure, automated testing and software delivery can sound like departments talking to themselves. A bill provides a translation. So does the time between finishing a change and getting it into customers' hands. These are things a business can notice without becoming an expert in the machinery.
An illustration of Garg's approach, not a prescribed contract structure.
The business also accommodates customers who buy differently. Garg described a roughly equal split between outcome-based work and a retained pod model in late 2025. Large organizations have procurement habits, internal constraints and projects whose boundaries are hard to settle in advance. His preference for outcomes survives alongside that practical concession. An invoice has to pass through the customer's organization as well as the founder's philosophy.
The founder cannot be every department
By December 2025, Garg was describing a company of about 600 people. The reported $10 million to $15 million ARR range gave a sense of its scale; it also introduced a different management problem. The habits that win early contracts can become difficult to repeat when every important decision still needs the founder's personal attention.
He distinguishes the early stage of chasing deals from the later work of building repeatability. Marketing, sales, finance and engineering all need capable teams. His next revenue ambitions require an organization that can keep moving when he is occupied elsewhere. The charming image of the founder doing everything becomes less charming when everyone is waiting for his reply.
This concern appears beyond a single interview. When discussing another podcast conversation, with Akash Kumar of Instahyre, Garg highlighted scaling past founder dependency, hiring and winning enterprise customers without an established brand. Those subjects fit together. A company that promises reliable delivery needs an internal way to produce it, including when the founder did not personally make the promise.
His attitude toward funding also leaves room for choice. In a May 2025 reflection on bootstrapping, he discussed profitability, delegation, possible exits and the option of raising money later. He presented a profitable business as a way to give founders alternatives. Those were scenarios, rather than disclosures of his own earnings or a promised sale. The aspiration was room to decide.
That is a personal ambition with organizational consequences. Building a company that can afford experienced leaders changes what its founder can spend a day doing. Building one that depends on a permanent emergency changes it too. Garg's interest in delegation gives the story a quieter measure of progress: how much responsibility can move beyond him?
AI comes with plumbing
AI has extended his argument about outcomes into another market. CodeVyasa helps companies prepare the data and infrastructure that AI systems need, while also using AI tools in its own delivery. These are related activities with different buyers' questions. One asks whether a system can work inside an enterprise. The other asks how efficiently a team can build it.
Garg has described the unglamorous work behind an impressive demonstration: data plumbing, access controls, integrations and governance. The list is revealing. A model may be able to answer a question, but an enterprise still has to decide which information it can reach, who may ask, and how the answer connects to work already happening elsewhere.
His public emphasis falls on implementation. He has discussed private language-model stacks for financial-services organizations and the changing balance between buying software and commissioning a custom system. These are bets about customer behavior, rather than settled predictions. They make sense within his own business: if companies want more software tailored to their operations, someone has to understand those operations closely enough to build it.
There is a human complication in that efficiency story. Garg has publicly asked how junior engineers become senior when AI performs the work through which juniors once learned. It is a question about the supply of experience. A team can enjoy faster output today while still needing people who will exercise judgment tomorrow.
For a founder who learned inside other people's growing companies, the question has particular resonance. Apprenticeship contains work that looks inefficient while it is happening. Someone is learning to recognize the mistake, understand the customer or finish a task without supervision. An organization that measures output still needs a way to make that education possible.
What he counted at five
On July 31, 2026, Garg marked CodeVyasa's fifth anniversary. His attention went to tenure: more than ten people from the company's first quarter were still there, more than sixty had stayed over three years, and nearly 80 percent of its leaders had grown from within. These were his reported figures, and they explain what he chose to celebrate.
The same anniversary brought a geographical step: setting up a local entity in the GCC and opening at WeWork in Dubai. He had already announced the company's Gulf presence earlier that month. The expansion carried an existing commercial idea into a new region, with relationships to establish and local experience still to acquire.
His ambitions remain explicit. He has described wanting to build a consulting business in data and product engineering with the stature he associates with McKinsey. The comparison identifies the kind of relationship he wants with customers: close enough to understand a business problem, and responsible enough to help carry out the solution. The work of earning that position continues contract by contract.
The calendar correction at the start now feels less incidental. Garg gives the years back to the story, then gives much of the credit to the people who spent them building alongside him. Selling an outcome may begin with a crisp promise. Keeping that promise repeatedly takes a company. His next task is making sure that company can keep its promises at a greater distance from its founder's desk.