There are 75 million small businesses in India. They employ nearly half of the country's workforce. They are the backbone of every city, town, and village economy — the kirana that opens before sunrise, the auto driver who knows every shortcut, the coaching centre that sends students to the IITs.
Almost none of them have software built for the way they actually work. That is the problem we set out to solve at Tanvrit. But solving it required us to first think clearly about what kind of software India's small businesses actually need — and to resist the temptation to build what is easy to demo rather than what is genuinely useful to use every day.
What a "Business OS" Actually Means
The term "operating system" for business gets used loosely, so it is worth being precise about what we mean. A business OS is not a single application. It is the integrated layer of software through which a business manages its core operations — billing, inventory, payments, compliance, and financial reporting — in a unified way, with data shared across functions and a single coherent view of what the business is doing.
The contrast is with individual apps. A business using five separate tools — a billing app, an inventory tracker, a payment app, an accounting package, and a GST filing tool — is not running on a business OS. It is running on five apps that may or may not share data, require separate logins, and produce reports that may not agree with each other. The operational cost of this fragmentation is higher than most owners realise.
A genuine business OS means: one place to record every transaction, one place to see your current stock, one place to understand your GST position, and one place to look at your financial performance — with all of these views derived from the same underlying data, updated in real time, accessible from the same device. This is not a complex technical achievement. It is a product design discipline that requires resisting the temptation to add features without thinking hard about integration.
The Real Cost of App Fragmentation
Consider a typical small retailer's current digital situation. They bill customers using one app. They track inventory — if they do at all — in a separate Excel sheet or a different app. They accept UPI payments through PhonePe or Google Pay, which has its own transaction history. Their CA uses a desktop accounting package to prepare GST returns, importing data manually or asking the owner to send WhatsApp photos of bills. Their bank statements live in a mobile banking app that does not connect to anything else.
Every month, reconciling these five sources of truth takes hours. Every month, there are discrepancies that require someone — usually the owner — to investigate manually. Every month, the GST return is prepared under time pressure from data that may have gaps or errors. The aggregate cost of this fragmentation, measured in time, errors, and missed opportunities (like ITC claims that were missed because the purchase invoice was not recorded in time), can easily exceed ₹10,000–₹20,000 per month in a business turning over ₹50 lakh annually. That is more than most SMBs pay for software in an entire year.
Why We Started With Billing and Inventory
When we mapped out what a business OS for Indian small businesses should include, we identified a long list of functions: billing, inventory, payments, credit management, GST compliance, supplier management, staff management, customer relationships, financial reporting, and more. We could not build all of these at once. We had to choose where to start.
We started with billing and inventory because these are the two functions that every retail business uses multiple times every day. A billing system that processes every sale is the data spine of everything else. Every sale recorded becomes an inventory update, a revenue figure, a GST output, and a customer history entry simultaneously. Get the billing right, and you have a foundation that can support everything else. Skip it or do it poorly, and no amount of downstream sophistication compensates for the broken data foundation.
Inventory was the natural second layer. A billing system without inventory is useful but incomplete — you know what you sold but not what you have left. Combined, they create the feedback loop that drives better purchasing decisions, reduces dead stock, and prevents stockouts on the products that drive most of your revenue. Every subsequent feature we build — financial reporting, GST filing, customer credit tracking, supplier management — is built on top of this billing-inventory spine.
The Challenge of Building for Low-Bandwidth Environments
India's internet connectivity story is one of dramatic improvement alongside persistent fragility. The average data speed has increased enormously with 4G and the beginning of 5G rollout. But "average" hides a wide distribution. A shop in a dense urban market may have excellent broadband. The same owner's second shop in a nearby residential lane may have weak 4G that degrades to 2G during evening peak hours. A shop in a tier-3 town may have intermittent connectivity that drops for hours at a time.
Building for this reality means more than adding an "offline mode." It means designing the entire data architecture around the assumption that connectivity is intermittent, not continuous. Data must live on the device first and sync to the server opportunistically, not the other way around. Every action — billing a sale, updating stock, recording a payment, printing a receipt — must work instantly on-device without waiting for a server response. The sync process must be robust to partial connectivity, handle conflicts gracefully when the same data has been modified in two places during an offline period, and never silently lose data.
This is significantly harder to build than a cloud-first app with an offline fallback. It requires a different database architecture, a different sync protocol, and a different approach to conflict resolution. But for a business that relies on the software to process every transaction, the offline-first guarantee is not a nice-to-have — it is the difference between a tool they can trust and one they cannot.
Mobile-First, Not Desktop-First: Why It Matters for Bharat
The default assumption in enterprise software is that the primary user interface is a desktop or laptop computer. Mobile apps are companions — useful for checking things on the go, but not the primary working environment. For India's small businesses, this assumption is entirely inverted.
The owner of a kirana store does not have a desktop computer behind the counter. They have an Android phone in their pocket and possibly a low-cost tablet on the counter. Their staff have no formal training in software. Their working environment is noisy, fast-paced, and demands that every interaction complete in seconds. Designing software for this environment requires entirely different decisions than designing for a white-collar knowledge worker at a desk.
Mobile-first means the phone is the primary device, not a secondary one. It means the entire feature set must be accessible and usable on a 6-inch screen without zooming or horizontal scrolling. It means touch targets must be large enough to tap accurately with a finger in motion. It means the critical workflow — completing a sale — must be achievable in under 30 seconds by someone who has never seen the software before. These are design constraints that shape every product decision, from how the catalogue is navigated to how the receipt is delivered to the customer.
Offline-First Architecture: How We Build It
Our architecture puts a local database on the device as the source of truth for all active operations. Every transaction, product, customer record, and stock update is written locally first. The cloud database is a synchronised replica, not the primary store. This means the app is functionally complete without any network connection, and the user experience is identical whether the device is online or offline.
When the device regains connectivity, sync happens automatically in the background. The sync protocol handles conflicts — for example, if two devices (a phone and a tablet in the same shop) both recorded sales while offline — using a last-write-wins or merge strategy depending on the data type. Stock counts are merged carefully: additions and subtractions from each device are applied in sequence rather than overwriting each other, to preserve accuracy.
The practical result is that an owner using Friendly on their phone at the counter and a staff member using it on a tablet at a second counter can both process sales simultaneously, even without internet, and the inventory database will accurately reflect all transactions from both devices once sync completes. This is the kind of reliability that builds genuine trust in software — not because it is impressive to explain, but because it never fails you when you need it most.
Our Philosophy on Pricing for Indian Markets
Pricing software for Indian small businesses is genuinely difficult. The segment is large but individually price-sensitive. A pricing model that works for a Western market — ₹3,000–₹5,000 per month — is out of reach for a business with ₹30–₹50 lakh in annual turnover and margins in the single digits. A pricing model that works for India — ₹199–₹499 per month — requires high volume to be sustainable, which means the product must be good enough to spread through word of mouth in tightly connected trader communities.
Our pricing philosophy has three principles. First, entry must be free — a small business must be able to try the product for real, with real transactions, before they spend anything. Second, the core workflow must be affordable at the base tier — billing, inventory, and GST compliance should not require upgrading to a premium plan. Third, the value delivered must be an order of magnitude higher than the price — if a retailer saves ₹5,000 per month in reduced shrinkage and avoided GST penalties, paying ₹299 per month for software is not a financial decision at all.
We also believe in radical transparency on pricing. No per-transaction fees that appear only after you start processing volume. No charge for data exports. No artificial limits on the number of products or transactions in the base plan that only reveal themselves once you have invested time in setup. The kirana owner has been sold to enough times by vendors who obscure the real cost — we intend to be different.
What's Next for Tanvrit
We are in the early stages of something we believe will matter. The products we've shipped — Friendly for retail POS, Swyft for mobility, Mandee for business management — are the foundation. We are expanding them, deepening their integrations with each other, and building the financial infrastructure layer that will allow a small business to manage their entire operation from a single dashboard.
The next layer is financial services: business credit for retailers whose transaction history we can see, insurance products calibrated to the actual risks of small Indian businesses, and payment products that let a kirana accept, track, and settle payments across every method their customers use. All of this is possible because of the data foundation that starts with a billing system used faithfully every day.
If you run a small business in India, we want to hear about your operations — the workflows that work, the tools that don't, and the problems you have quietly accepted as unsolvable. If you build software and believe in this mission, we are always looking for people who want to work on hard problems that matter to the majority of India. See the full Tanvrit platform →