Full Stack Greenfield Projects : Are they still relevant?

Okay, good morning. It's a real pleasure and honor to have Mr. Bharat Goenka with us today. Uh, you know, we just met last month and I was really struck by his insights and you know, his uh uh, enthusiasm for technology and so on and I thought uh, so he's a co-founder of Tally. He founded it with his father 35, actually 40 years ago. 40 years ago. Uh, I think it was the first software product company in India and it has gone uh, to amazing scale like 4.8 million customers in India as well as across 100 countries, I think. Uh, and it's been amazingly successful. Uh, he has received many honors, the Padma Shri, the NASSCOM Achievers Award and many others. Uh, he's also a very uh, enthusiastic and heavy user of AI. He was just telling me that he he uses 80% of the AI tokens in his company, right? Uh, so uh, and he has, you know, views on what works and what doesn't work as well. So, looking forward to his insights. Thank you. >> Good morning, everyone. And thank you for being willing to tolerate me. I'm a very scattered speaker, so I want to just set that context first. Uh, since it's a short and for me it's a short lecture. I I tend to make seminar 8-hour talks in my company. And uh therefore, I will start with with the the topic I selected. And the topic I selected was this this concept called full stack green field. Right? And and I the question which I I posed in that uh statement was is full stack green field, does it even continue to be relevant? And the the question was not to see if I can get an answer from all of you because right now, for the last 5 years, I've been working on a full stack green field project, so I don't care whether anyone else believes it's relevant or not. But it was more about explaining what the difference between uh full stack green field and the way the word green field is traditionally used in software or brown field sometimes gets called uh used in software. And if something is neither green field nor brown field, then what type of software project would it be? And uh therefore explaining why as a company this is our sixth full stack green field project without yet explaining what that term means. And for a software product company and we're a single product company, we sell just one product called Tally. We have just one audience called Tally. The one audience for that product. Which is the SMBs. And uh for a company to do a second full stack green field on the same product is the single largest risk any product company can ever take. Uh and we've done it five times before. This is the sixth time we are presently doing it. So what is full stack green field? Full stack green field essentially says that you use absolutely nothing of an external stack. Absolutely. Right. And for business software, that is completely unusual. You require a database, you build your own. You require a GUI engine, you build your own. You require math routines, you build your own. You require uh the way business objects are operated in memory, you build your own. And and And the question becomes, why would anyone do such a thing? Why What does it get you? I mean, apart from intellectual satisfaction. And because it's fun doing it. And uh Is that the way we think that every project should be done full stack green field? And the short answer is no. But literally every single time we have landed up with full stack green field. And therefore, I want to give some examples of why it landed up to that place. So, I'll take history from most of it, which is irrelevant, but still it's has continues to have some relevance. We are sitting in India, and we are sitting in India 2026. And some of you at least are old enough to remember India in 1986. But most of you were not even born at that time. But most of you remember the progress India has made. But in spite of whatever progress which has been made, right now as we are sitting here, for any reason if the lights go off, hardly any of us will be surprised. We know it is gone off, it will come back in a couple of seconds at the generate generator takes over and so on. It is It is a normal phenomenon of life that electricity, while stable, is not expected to be as stable as some other countries. In fact, about 30 years ago, there was a 15-minute blackout in New York. It made headlines in India. Right? Why is that relevant? So, we were building software for the SMB, and assuming and we had our options were to use an uh IBM ISM DB. We had in those days DB2. Uh Microsoft had not yet come with a productized DB. But uh so, there were these four or five so-called options in those days of of databases. And they had own tool sets as well as their own so-called administrative capabilities to recover from corruption of the underlying database. When does a database get corrupted? It gets corrupted when in the middle of a write. So, leaving logical corruption, there's something is wrong with your software. So, you assume that your software is not wrong. So, then when the why does it get corrupted? It's not just because of media corruption. It gets corrupted because you don't expect a write to be paused midway and leave the underlying DB in an unstable state. UPSs in India in 1986 did not exist. How would you sell product software to people who are in some other city and they are supposed to now use take it, install it, run it, and live in an environment where power is unstable. And when the power does come back, they should be able to come back and continue their work. The problem is the tech tech does not exist. The tech has to be created. First, the problem has to be confronted. First, you have to look at not the functional side of the problem. We have to look at the what will prevent this from actually reaching someone that beyond a demo. It's very easy to construct anything on top of existing stacks. Create a demo. In fact, you can hand it over to someone. But then expecting it to remain with that person's running life, that's when you have to look at what are the circumstances that person is going to go through. It's just a starting of illustration of an example. Then we take the others parts of it. All of us you are creators and all of you are consumers of tech, of software, of everything else. There are some things that we all tolerate because we have no option. And and uh rather we don't have a better option. So the things that we tolerate, the persons who have built that are benefiting from what is called the TINA syndrome. There is no alternative. And and sometimes people get confused by the TINA syndrome to think that they have done something good. They don't even confront the fact that it is only tolerated. And the moment there is an alternative, the user shifts. And you look at yourselves as consumers, when is it that you wanted to shift to something else? And I'm going to make a blanket statement. 90% or greater I would go as far as 99% of the time, you will want to shift not because something has got greater functionality, but it's just more delightful to use. It's faster. It is is far more responsive. It's just it's just more lovable because of that fundamental character of it. And the things that you tolerate are things which don't have those characteristics. In 1986, the underlying hardware was 4.77 MHz. The total memory was 640 KB. The largest hard disk you had was 20 MB. Processors have gone to multi-thousand of that capacity. Memory has gone to multi-thousand. Those days networks did not exist. Network speeds have gone insane. Storage capacity has gone insane. Access to distributed computing has gone insane. Surprisingly, not all software has gone to that same same speed. The reason being that as the underlying hardware has improved, the programmers are lazier because they need to do less, and they can do things faster, and they can bring in more functionality, and no one needs to solve the lovability problem. We don't just have 2.7 million customers. I'll explain a couple of emotional attachments to it to then help you all understand why we do full stack green field, and therefore which other aspects of full stack green field we do and now what one is doing. We had a customer in Ludhiana and I'm genuinely saying had a customer in Ludhiana because we are built for the SME. We are not built for the much larger enterprise. And uh he is one of the largest department store owners of Ludhiana. About I think 30 department stores. You can buy anything from a hairpin literally you can go and buy machine guns there. You can buy motor cars there and legal of course. I'm not saying you can buy motor cars, motorcycles. You can buy everything anything that Ludhiana has to sell you'll find in one of his stores. And uh he attributes his growth story to Tally. And as he started expanding he outgrew what Tally was built for. And he kept pressurizing my company to solve his problems but our architecture was not even built for that scale. So beyond a point you can't you can't bend something and make it do something. Uh I became aware of his pain about 2 months about 8 months after he was suffering and then for 2 months we kept telling he kept wanting to meet me. I was traveling. Ultimately came down to Bangalore. And I'm sitting across him. His name is Surendra Pal. I said Pal Saab first I'm sorry that you had to travel all the way from Ludhiana. I would have come. Unfortunately I'd been traveling. And uh because I'd heard the history from my my team and I kept telling them why have you not told him to move out of Tally? They said he doesn't listen to us. I said don't worry I will tell him. I said Pal Saab first we are all so happy that you have become one of the largest department stores in Ludhiana. That's great. But I must honestly admit to you, Tally is no longer for you. Someday we will come with a product which is built for you. As of today, don't constrain your business by using Tally. It will stifle your business. He got up. He was sitting on the opposite side of the chair. He's a Sardar. He stood up. Rolled his sleeve up. Yeah, there was a person sitting next to me. He would tell that boy He told in Hindi, but I'll tell tell it in English. Tell that boy tell him to go and get a knife. Get a knife. Cut my hand. Every drop of blood will tell you Tally. He's a customer. He has paid money. He's bought a product. He has a right to demand the product services purpose. What about it will allow a customer to get disassociated with the product? And this is a not an isolated story. I am proudly standing up and telling that you can go out in the market and you can randomly pick up customers and ask them their emotional connect. What are you I got we got customers who got Tally tat Tally tattooed on the neck. Literally, the logo is tattooed there. We got four people who have changed their surname to Tally data. It's nothing but a software product. If you come down to its basics, it's nothing beyond nothing else. It's just a software product. Which is the last software product that you used which made you feel to do something like that? You owe this is what I want to do. And can you imagine that software product coming alive without someone building every part of that stack and built on things which everyone else builds on? Because it's never functionality. Because functionality, everyone in the world can give it to you. It's the same fundamentals of What is functionality? It's data on disk. It's data manipulated memory. It's data how it went into disk. It's how that data is taken out and how it is represented back. Right? Any given functionality can ultimately be broken down into the some few fundamentals. What about it will drive that emotion? It is literally at what speed it will happen and why will it happen at that speed. What constrains it? So, I'll take examples of the speed. And then you all can try to imagine that without building the DB yourself, how would you to get that speed? You've got 15 years worth of data. And each year is what and we'll keep the numbers modest. Each year has got only about 5,000 or 10,000 transactions. It's about 150,000 or 180,000 transactions scattered across obviously these 15 years. Approximately 4,000 days of data. And surprisingly, for a variety of reasons in law, up to a particular period of time, law itself can tell you that that data is to be modified because you computed it wrong. But apart from that, there are enough unstructured reasons why people will want to do that. First, we were the only software company in the world which it recognized that people will need to change old data, not pass a rectification entry, which is what traditional software does. They They treat it as that if I have entered some transactions, I can only pass a correction entry, which means someone who's looking at the transactions will encounter the old transaction first, which cannot be modified. And until they encounter the correction, they don't even know it has been corrected. Right? But literally every software in those days, that's Well, that's the easiest easiest software to develop. The problem is not whether you can modify that entry. The problem is now what is the cascading impact of that entry, and how soon can that cascading impact become visible on your screen? And uh we will still stand up to claim that we are the only software in the world where you could be looking at a report from any arbitrary date to any arbitrary date. And starting from any arbitrary date means that there has to be some computation of what the opening balance is associated with that arbitrary date is. And you can take any arbitrary date. It's not a weekend, it's not a month end, it's not a year end. It's literally any arbitrary date. And you could be looking at that report and you could have now gone and made a change anywhere or forget about my making a change. Someone else who is on the same system, on the same company and in a multi-user environment has gone and made a change. And I will use the word instant because you will not be able to measure it using a normal clock. You can only measure it using computing instrumentation. As far as the user is concerned, the impact is instant irrespective of the underlying data range. It's not just about the disk speed, it's not just about the DB, it's about And you have to do this in constrained environments. I'll come to that last point about full stack. And then last few minutes I will touch on the what we are presently doing and what makes it exciting. Our market is the SMB. In a book called Zero to One by Peter Thiel, he explained that market as the dead zone. And he broke the market into three saying there's a enterprise market, which is the most romantic market for people because that's where the money is. Then do you have the SMBs and then you have the consumer market. For the enterprise market, companies run a sales engine. They And and therefore the the cost of technology for the enterprise uh needs to absorb not just the cost of the technology but also the cost of servicing that technology through the sales engine and support engine and so on. So, that's what they run. The consumer cannot obviously cannot afford a sales engine. So, the consumer market is run through what you will call marketing and distribution. And the consumer is all always self-serviced because that's the only way they can you can hit the the affordability uh barrier of that. So, the way you think about both building and distributing for the consumer market and make money out of it is different from the way you think about it from the enterprise market. The SMB is a strange animal. Its characteristics are like that of an enterprise, but its affordability is that of a consumer. So, no one can afford to run a sales engine. In fact, if you look at the US uh and most advanced markets, they treat the SMB in the same market as the consumer. So, they run they treat the SMB as a self-service consumer. And developing markets like India, like Indonesia, like 80% of the world actually, uh the SMB behaves like the enterprise, but cannot afford like the enterprise. Uh examples of that is that you go to you go to Chickpet. I I know for those who are familiar with Bangalore, go to Chickpet, go to a small shop there. The shop owner there uh when he leaves the shop to go home, he will do his own shopping for groceries, for coffee, for tea, for a bottle of water. But in his shop, everything is serviced to him. He doesn't go out to buy for a shop. He's not a self-service shop. As a shop, he expects people to come to him. He expects the chaiwala to come and give him chai. He expects the paniwala to come and deliver water to him. Everything is serviced to him. That is completely unlike all developed markets. Such people cannot afford the devices on which you as a software engineer can make your software fast. So, if you want your software to be loved, it has to be fast on the devices that they can afford. That is a completely different ballgame. [clears throat] It's very, very easy to take advantage of progress of the stack and progress of hardware and say, "Oh, of course my software runs fast. You just require to upgrade." Oh, they can afford your software, they can't afford the underlying device. These because of the nature of our market and this this pension of saying, "It's not enough to sell your software, it it's important to get your software and loved." is what has made us uh perpetual full stack green field company. In the current project that we are doing, we are going taking the full stack statement even one step further. Uh not for the end customer, but for our back-end systems. Uh because we are now aiming beyond 2.7 million customers. So, 2.7 million customers for us are business customers. Generally, when people use 2.7 million customers, everyone hears 2.7 million users. No, they're not 2.7 million users. They're 2.7 million customers. The number of users we genuinely cannot count because we don't do telemetry on that. The number of companies on which Tally is used we genuinely cannot count because we don't do telemetry on that. We have anecdotal examples of a single chartered accountant with a single license of Tally running the accounts of 800 companies. We have what anecdotal examples of one large uh organization with a single company with one license of Tally with 108 users on it. They're anecdotal. They aren't They're not the norm. So, I will I'm not going to claim that 2.7 million into 100 is That's not the purpose of the point. The point is 2.7 million business customers sometimes does not get the understanding of the diversity and scale of the adoption that we have in the market. Even today, every single day we have 500 to 800 literally one customer per minute not just buying Tally. For an SME the cost of the software is the easiest thing for you to solve. You own the You own the pricing model. Right? So, if I'm willing to take a lesser price lesser profit, I can sell it to you cheaper. Big deal. So, that's why I first took one side of the cost puzzle, which I don't control, which is the device you have to buy. So, if my software doesn't run on a device you can afford doesn't matter what price I make my software. The second is what is the cost you will incur after you buy my software? What are the cost of implementation you will take? How much effort that you will require in terms of people to help you? How much time will you take to get the software up and running? We are the only software in the world genuinely I'm making these as It sounds like very sweeping statements, but I can challenge you all to find an equivalent business software where if you have purchased the software at 9:02 in the morning at 9:03, you are entering your first live transactions all on your own. Live transactions. Yeah, you can take your next invoice that you are making to a customer and feed it in and that invoice is not a trial or let me figure it out how the software works. Nothing. So, you cut the affordability on all sides for the customer. So, when we say we have got 500 of one customer a minute is not just one customer a minute buying our software. It's one customer a minute adopting and moving their business onto Tally. That's really unusual for a business software which is labeled an ERP. And for the SME, it is an ERP. And to be able to make a statement that you can implement an ERP out of the box they are they are fantastical statements. From this 2.7 million, we are now aspiring for 200 million. Uh the world has changed. We have got infrastructure in the back end. Tally as it's there in the market today uses some bit of it, but it's not built backwards against this connected environment. The world was not connected when we looked at the way software is being was written for the SMEs. Today uh actually, you don't mind [clears throat] the power going off as much as you mind your connectivity going off. Right. Uh it is not it still remains an occasionally disconnected world, but it is more and more people are taking it for granted that you will be connected. But except for personal productivity in business and various other things businesses are not connected to each other over connectivity. I was just sharing with Venkat a short while ago that businesses by their nature are not islands, right? They have customers and suppliers and bankers and governments. They have They have things that they deal with. They're not sannyasis, as you can call them, right? Because that's what makes it a business. You can be an introvert and not talk to anyone, but you can't be a business and not talk to anyone. It's the the very purpose of a business is to have interactions. But business data by default, not just by default, by design, does not talk to business data. That's the world that we are set out to change. That's why we are calling it a civilization-changing project. That that uh can businesses of tomorrow take it for granted that data naturally talks to each other. It is much more complicated than this high-level vision. Uh because I'll take some examples to illustrate that. I'm a manufacturer of pencils. The way I think about pencils, the way I think about this SKU called a pencil, is actually a very elaborate concept. Like what type of material is there for the cover of the pencil versus what are the material which is in the lead of the pencil because different types of lead is there for different types of what they call hardness and blackness. And uh for different purposes for the artist versus the uh uh architect as people do drawings and so on, right? So, as a manufacturer, and then there is lengths, and then there is shapes, hexagonal versus round, and and with the rubber, without rubber. So, the point being that for me as a manufacturer to deal with that so-called SKU is a very elaborate process. From me, it goes to a distributor who cares about some of these distinctions, but not the same level of distinctions that I do. At some point, it reaches some neighborhood shop of yours. That neighborhood shop frankly doesn't care what is the difference between a 6 8 and a 2 B and a As far as he's concerned, some school child comes to that person and says, "Hey, give me a box of pencils." And he gives them whatever box of pencils this person has got. Right? He doesn't care whether it's Apsara or Nataraj or anything else. Now, how do you connect all of this this entire chain of people who theoretically are dealing with the same product, but mentally, they are not even dealing with the same product. Right? In fact, if you go to I my daughter recently her favorite example is going to a shop on the road to Mysore. And because now it's uh my son and my daughter run tally, so they are interested in how people run things. And uh she bought something on the shop. She got an invoice. And the invoice said one BMW. What did she have in her hand? It was a bottle of Aquafina water. What that invoice told was So, she asked the person, "What is BMW?" She said, "Bisleri Bisleri mineral water." For that person, that is a noun for mineral water, the BMW. It didn't matter for him that he has actually sold her Aquafina. Or he would have sold whatever the stockist would have given. Now, when you want businesses to be connected and an invoice that I have made as a stockist reaches such a person which is supposed to become your data. How would you connect these dots together? So, I just wanted to illustrate that technology makes you aspire, but to get that aspiration to become manifest, you have to first break down the problem and then discover which technology does not exist today, what has to be created, and from there does the aspiration start unfolding. To solve this problem, we are even going to create our own OS because in a connected world for 200 million customers, about a billion users, the of which 89% percent of them will not be able to afford our software. You can't make a loss with every customer and hope to make it up in volume. Right? And this is a business customer. So, they don't act like consumers. They are not going to self-service. So, every cost that we incur is a cost that the customer will pay in some form or the other. So, what is the largest cost at the back end? It's not compute. It's a declining cost. It's not memory. It's a declining cost. Year on year, it will decline, of course. Not recently after AI went crazy, but in general, you can say infrastructure will decline. But, the cost of managing that infrastructure, even if your team size did not increase, will go up. The team expects increments every year. They expect a better lifestyle every year. So, how do you build for infrastructure which will not require large teams. Right? So, this is just another illustration of the types of problems that we try to deal with without getting constrained by what any existing stack provides. We get inspired by all stacks not to see what we can copy, but to understand what constrains them. And therefore, what stack which is built, sorry. It's getting late. >> No, no. I I had a question. >> Sorry, yeah. >> Uh how do you solve this BMW problem? The stockist might have written Aquafina. >> Yeah. But, this shopkeeper wrote BMW. Yeah. Yeah. So, this So, there are you are looking at, I would say, different levels of abstraction. Right? So, when you mentally say that my abstraction and your abstraction has to match, this is an unsolvable problem. Right? But, the fact that my abstraction can match with something for you is a one-to-many. That means many different abstractions can match to yours. Then, it starts becoming a little tractable problem. Within your mind, irrespective of what label you're giving it, the abstraction you're using is bottled water. Now, incidentally, whoever gives you bottled water can land up in your abstraction without conflict. Right? >> Yeah. >> So, the problem there is to first be able to see how can you granulate abstractions because you don't care how do I treat it. You only care how you run your business. I don't care how you treat it. I only care how I run my business. This abstraction is a technical problem. It's nothing to do with the humans. At the human level, neither of us ever had any problem in talking to each other because we never attempted to align our abstractions. At a technical level, we try to make it very very precise. And that's where the struggle happens. And the problem is not about just solving it now. The problem is now Today, that's your level of abstraction. And just like Surendra Pal, you grow and you become more structured. As you become more structured, your lens of abstraction will change. How does your old data remain relevant and how can you change to a new abstraction? Because if you can't do that, in any case, you will come you might become a customer of Tally, but you will stop remaining a customer of Tally. Right. And if the bucket leaks, you can't get to 200 million. Sorry, I shifted the problem, but just to explain to you where the problem is even larger than what you said. Does it help a little bit? >> Thank you. Yeah. >> You have about 10 minutes just to >> Sure. Sure. Sure. Yeah, I think I think I think I I I do have this bad habit of a monologue. So, first, thank you for interrupting me. Uh in fact, most of my 7-hour 8-hour lectures in the office, I need to tell them that, "Look, for a variety of I don't know you I'll call it biological reasons or not, I don't require to take a coffee break or water break or bio break. And I said that you all can sit and suffer or you all can interrupt me." Right. So, I should have started this session also with the same thing. Right. But, uh I hope I was able to explain first what we mean by full stack green field. Where the purpose is how do you break the assumptions of constraints because if you start with something it's you no longer are dealing with your problem. You're dealing with a a a possibility of a solution space which is already constrained and it is assumed that those constraints cannot be broken. So, unless you are first willing to go past that and the work that you all are doing and because you all are in MSR, right? Your job is to to go below the constraints. Right? It's If you invent on top of constraints without being willing to question why does the constraint exist at all, then even if you live with the constraint, it is a a wear living. You don't need to solve it. We're not trying to solve can we create a keyboard? We We actually examined that 25 20 years ago when we did our first multilingual tally. And our multilingual tally was not about can I use it in English, can he use it in Kannada, can he use it in Tamil? That was not the purpose of the multilingual tally. The multilingual tally was can I use it in Gujarati? And I'm a Gujarati shopman shopkeeper in Ahmedabad. But my customer in my neighborhood happens to be a Tamilian. I don't understand a word of Tamil, he doesn't understand a word of Gujarati. I can't read Tamil, he cannot read Gujarati. Can I create an invoice in Tamil and give it to him? Right? So, the the language model was meant to be concurrent. The constraint was how does people how do people have keyboards which will allow them to use a language input? So, we explored that that can we get keyboards where instead of the embossed lettering, can we make the keyboard soft, a physical keyboard soft? So, when I select my language, the the lettering changes and so on. The We never got into the project. We said, "Okay, we will live with it." But you don't leave it unexamined. You don't leave your constraints unexamined. You choose your constraints and not live with them. That's the So, while in the market we are known as a accounting software product company, the DNA of the company, in fact, the reason why I know Manohar has been that many, many years ago he was part of the team who was charged with finding out whether because we had applied to the Department of Science and Technology to be called a research organization. And they said, "We are a software company. What do you mean research organization?" So, he was charged with with trying to see whether we are faffing around and we are just wanting to take income tax advantage. In fact, we never landed up taking any income tax advantage. But But the the thing was that uh the the DNA of the company is to look beyond constraints. And therefore, we naturally think in terms of full stack green field. So, I felt it might be relevant because of the nature of work that I'm doing, and I have personally encountered enough people who automatically assume the underlying constraint. Because the moment you ask them, "Why don't you do it differently?" The first answer is, "No, but the system doesn't allow it." And in in their mind, the system is the DB they're using or the reporting tool they are using or the visual tool they are using or something else that they're using. And And therefore, for them, that is the constraint space on which they have to figure out the solution. Right? And uh the more you train your mind to go beyond the constraint space, you stop becoming a victim of constraints, and you become a chooser of your constraints. So, I hope it was useful. Thank you. Thank you. >> So, I have one question given that you only have one product. There is a risk that if you release a new full stack all your customers might >> All of as far as they are concerned, they might as well buy their next product from some another company. >> Yes, so they >> As far as they are concerned, it's a brand new company. >> So, how do you manage the risk of releasing something completely new? What kind of tests and other things you do to make sure that >> We have we have >> What do you do to start releasing you only release to a >> We have an amazing and arrogant confidence. Which which actually comes from a different perspective. I made a point. No one in despite Surendra Pal's dramatic statement of cutting his hand, despite that we are very clear there is no such thing called customer loyalty. A customer is neither married to my product or married to some other product. A customer is married to their business. Uh perhaps my next product does not turn out to be the best for their business. And therefore they move to something else. It's my onus to build the best product. It's nothing to do with will the customer choose me? The customer will always choose the best. The customer does not choose first to market, does not move choose fastest to market. This whole concept of fail fast is actually keep failing fast to fail forever, honestly. Right? It is it is just to make yourself feel that you are progressing because you got something in your hand or this so-called MVP that make the minimum viable product because you've got now something that you can ship. You can take any See, software is a 0 1 game. And Microsoft is one of the examples of it, right? That you either win everything or you lose everything. So, will our next release lose us everything? The answer is yes. Then the release after that, can it make us win back everything? Then again, the answer is yes. You just have to have complete confidence in that fundamental reality. So, it's not arrogance. It's just recognition of the nature of the industry. >> Thank you. >> Yeah. >> How do we create thousands of companies like Tally in India? >> Mhm. >> Should Should we follow the Tally model of entrepreneurship? Are there different ways we can do this? >> I think the enough people have done a lot, right? I mean, they See, we have we have achieved something in one particular way. Uh Could I have built an Infosys? The answer is no. Uh Could I have built a Flipkart? The answer is no. Right? So, there are people who have done some things extraordinary, population changing environments. So, I I don't think it's just So, the techniques that we use, we call it the Tally way actually in internally. We call it the Tally way of uh business and product design and Tally way of engineering and stuff like that. >> That's what I meant. Product companies. >> Yeah. >> Where you create your technology and you're not afraid to take the risk and you really want the customer to love your technology and buy it for that reason. And this is not just within India. It's for the world. >> Yeah. So, I think the first thing is to be able to propagate the fact that 90% of whatever you will find of software development techniques in colleges, in the in the websites, and and inputs you will get from Copilot and others. 90% of all of that is not meant for product development. Because 90% of the lines of code written in the world are meant for custom development. Right? So, the techniques have fine-tuned towards that. The whole concept of modular engineering, all of them have been fine-tuned uh towards that. Just the way marketing is fine-tuned towards consumer marketing. No one No one actually teaches you B2B marketing. Because it it's a niche subject. Product engineering is a niche subject. The first until that recognition is stuck to a person who's wanting to build a product company. So, I have come out of college. I have learned software engineering, but my software engineering basis basics are for custom software. I have not even been taught the fundamentals of product engineering. So, it starts from saying that how do you first expose people to what is the difference between the two? And the the What is the difference actually between a software application and a software product? If I If I ask that question, uh I don't think people will give a precise enough answer. And we defined it for ourselves 35 36 years ago that the use of the word product is where a completely unknown buyer can buy something from a completely unknown seller and be able to successfully use it. So, the same physical thing like a cake, you go to a bakery and you can buy the cake from the shelf. That is not a product. Contrasted with you go to a department store and you buy a packaged thing which you open and it still turns out to be a fresh cake. Now, the journey to make a cake which can be sold on a counter to a cake which can be sold off a shelf. That is productization. They are both physical products, but people keep using the word product to say something physical. No, they are not physical. The word product is a tradeable commodity. How do you build How do do you engineering to make something tradeable is completely different from how do you do engineering to make something usable? That's when you will get product companies. As as a starting point, right? Because then you will start thinking differently about engineering. When I don't know which customer is going to use my product, the way I think about usability changes. When I don't know which customer is going to buy my product, the way I think about packaging it changes. A lot of things change. I didn't want to make it sound like a very complicated answer, but these are fundamentals. >> Maybe I can ask the last question. >> Yeah, please. >> [clears throat] >> Uh first of all, really enjoyed your talk. >> Thank you. >> The question I have is when you talk about constraints and looking beyond constraints, how far do you think do you think we can push it? For example, maybe in your own business, right? Accounting and taxation and so on. A lot of the rules and so on are >> Yeah. >> man-made. They're They're not They're not, but they're made by humans. >> Yeah. >> Maybe they're unnecessarily complex. >> Yeah. >> A good example is I think a few years ago in the US, the government there decided that they will simplify some tax thing so that for 80% of the people tax filing would be automatic. >> Correct. >> But, I think companies like Intuit and so on protested that and they wanted to retain the complexity, right? So, my question is when you look at beyond constraints, do you think we should be able to >> try to influence everything as a company also. So, we we have been influencing the government for the last several years. We have been Not all our inputs get taken in, but a lot of the uh behavior of GST we have been involved from the time the word GST itself was coined. To say that what can be done to to simplify the tax regime of India. Uh so so those are largely constraints outside your control, but you still try to see if you can influence it. Then you have hard constraints. So, as an example, uh in the new project, we continue to be the only stupid people. Generally, I'm using the word stupid people. To say that our customers must get software on their hands and not software on the cloud. Right? And the reason being that when you are looking at 200 million customers, and you look at the distribution of computing at the back end, and you look at the internet latency latencies involved, uh at the end you have a physical limit, the speed of light. At beyond the speed of the overhead of electronics in the middle. So, a round trip from India to the US, you cannot reduce it below beyond 200 milliseconds. And everyone else in the world is wanting to go thin client, and until we give Tally, people have are in the TINA environment. They have no alternative because no one else is giving it to them the experience that we are going to deliver. And I believe in spite of Microsoft Word, Office 365 being online, your Outlook being online, I would say that the bulk of the people in this room still tend to use a local client for their work. It's not that you always start a browser and do your work. And the question becomes that when that is what you want to do as an individual, why do you expect others not to want that? So, there is a boundaries of physics you can't overcome. Then there are certain things which we are not choosing to overcome, but certain companies do. We are not intending to make our own chip, even though we are intending to make our own OS right now. So, at certain points, you do live with your boundaries, but you do it with with deliberation rather than fatality. You're not a victim of your boundaries. >> All right. Let's thank Mr. Gokul again for the >> Thank you. Thank you.