The hard part was never the model
June 2026
Nearly every small business in India keeps its books in Tally. Not some. Nearly every one. And almost none of them can get their own numbers back out of it.
This sounds like it should be a small problem. The data exists. It is sitting on a machine in the back office, usually a Windows box under a desk, and it is complete and current and correct. The owner just cannot see it. They can see it the way Tally wants them to see it, which is as a ledger, not as an answer to a question like whether they can afford to pay a supplier next week.
So you go and get it. And this is where most people stop.
Getting it out means an ODBC layer that was clearly not designed for you, an XML dialect that is only partly documented, and a desktop application built for a different era of computing. It means learning the quirks of how a twenty-year-old accounting format represents a voucher, and then learning the different quirks of how the version from four years ago did it, because your customer has not upgraded and is not going to. It is not hard in the way a distributed systems problem is hard. It is hard in the way that cleaning out a garage is hard. It is just a lot of unglamorous work, and it does not end.
I have been doing that work for years now. TallyKaro was the first honest attempt: a desktop connector that reads Tally over ODBC, syncs it up, and lets an owner ask questions over WhatsApp, because WhatsApp is where these owners already are and no amount of me wishing otherwise will move them into a dashboard.
Here is the thing I did not expect. That plumbing turned out to be the whole advantage.
Right now everyone is building on top of the data. Point a language model at a clean spreadsheet and you get something impressive in an afternoon. The demo is easy. The demo is so easy that the demo is worthless, because your competitor can also build it in an afternoon, and so can their intern.
What nobody wants to do is go and get the data in the first place. It is boring, it is specific, it does not compress into a slide, and it takes a year before it works properly. Which means that if you do it, you are holding something that cannot be reproduced over a weekend. The moat is not the model. Everyone has the same models. The moat is that you did the tedious thing and they did not.
I think this generalises. When a capability becomes cheap, the value moves to whatever is adjacent to it and still expensive. Intelligence is getting cheap very quickly. Access is not. Access is still a matter of someone being willing to sit with an ugly format and an uncooperative API and a customer who will not upgrade, and making it work anyway.
So when I look for what to build now, I have stopped looking for the clever part. I look for the part everyone finds beneath them. That is usually where the defensibility was hiding the whole time.