The beginning
What I saw before I built anything.
I grew up around clinics — not as a patient, but by watching them closely. Seeing the people behind them, understanding how they function, witnessing the invisible chaos that keeps healthcare running every single day. I come from a family of doctors, so clinics were never just buildings to me. I saw reception desks trying to manage long queues, doctors carrying immense pressure, staff juggling endless tasks, and administrators trying to keep everything together.
And over time, one thing became very clear: healthcare professionals spend far too much of their day fighting systems instead of focusing on people. The problem was never a lack of effort. Clinics work incredibly hard. But many still operate with disconnected processes, outdated tools, or software built for large institutions — not for the smaller clinics and growing healthcare centres that form the backbone of healthcare in India.
That thought stayed with me. As technology transformed almost every industry around us, the clinic level of healthcare still felt underserved. Not because the need wasn't there, but because meaningful solutions kept arriving with complexity, cost, or both.
"What if even the smallest clinic could operate with the efficiency and professionalism of a world-class setup — without enterprise-level costs?"
Before a single line of code was written, I spent time in clinics — not to validate an idea I had already formed, but to understand what an actual morning looked like. I sat with front desk admins who could manage a room full of waiting patients and a ringing phone simultaneously, but could not find a returning patient in a paper register fast enough. I watched doctors write the same information three times across different forms. I saw billing recorded in a separate notebook from registration, with the predictable consequences.
The existing software hadn't solved this. Every clinic I visited had either tried a product and abandoned it, or was using one in a reduced way — logging patients, and nothing else. Too complicated. Too slow. Designed for a hospital, not a clinic. Built somewhere else, for someone else's problems.
The realisation
It wasn't a technology problem.
The assumption most people make about clinics that haven't digitised is that the barrier is technology. That if you gave them the right app, they'd use it. This is wrong. The clinics I visited weren't afraid of technology. The front desk admin at the first clinic I visited was faster on WhatsApp than most people I know are on a laptop. The doctors used smartphones, UPI, Maps, and Google without thinking. The barrier wasn't technology literacy.
The barrier was that no one had built something that matched the actual shape of their day.
"The software built for Indian clinics was either designed for hospitals — too heavy, too expensive, requiring dedicated hardware — or it was built by people who had never spent a morning in a clinic that wasn't their own."
The front desk admin at a small clinic doesn't have 45 minutes to learn a new interface. She has 30 seconds between patients. The doctor doesn't have time to navigate a complex form. He has, at best, 10–12 minutes per consultation and a queue of 20 people. The software that exists treats those constraints as inconveniences. ClinOps was built to treat them as design requirements.
The realisation that changed everything: this wasn't a technology problem wearing a business mask. It was a design problem wearing a technology mask. The right answer wasn't more features. It was fewer, better ones — built around the specific, non-negotiable rhythm of a working clinic day.
That's when I decided what ClinOps had to be: not a system that clinics adapt to, but one that adapts to them. Not a feature list, but a workflow. Not a product for the Indian clinic market, but a product that could only have been built by someone who'd spent time in one.
The decisions
What we chose to build — and why.
Building ClinOps involved a series of explicit decisions — not features selected from a wishlist, but choices made in response to specific things I'd seen in the field.
WhatsApp, not email. Every patient in every clinic I visited communicated on WhatsApp. Not one of them expected a clinic to email them. Prescription delivery, follow-up reminders, and appointment confirmations in ClinOps go to WhatsApp because that's where Indian patients actually are.
Phone number as the patient identifier. In India, the mobile number is the universal identifier. It's what patients remember, what the front desk asks for, and what connects a person across visits, family members, and follow-ups. ClinOps is built around this reality.
No hardware requirements. Every clinic I visited had a phone. Most had a laptop or a tablet. None of them wanted to buy dedicated hardware just to run clinical software. ClinOps runs on whatever you already have.
Multi-sitting billing built in. Dental clinics, physiotherapy clinics, and any practice with treatment plans need to track progress across multiple sessions. Most clinic software ignores this or treats it as an expensive add-on. It's in ClinOps from day one because it was in the waiting rooms I visited from day one.
DPDP 2023 compliance from the ground up. The Digital Personal Data Protection Act 2023 applies to every clinic in India. Consent capture, encrypted storage, audit trails, role-based access — these are built into the architecture, not bolted on as an afterthought.
Where we are now
Early access. Early partners.
ClinOps is live. We're working with clinic partners in Bengaluru and Pune — early adopters who joined before the product was finished and whose feedback has shaped every iteration since. They are not beta testers in the traditional sense. They are the reason the platform is what it is.
Dr. Karishma at Dcure Dental Studio is a dentist who had never used clinical software before ClinOps. She was sceptical. She is now the reason we have multi-sitting treatment plan billing, because her workflow revealed how inadequate our first version was. Dr. Rohan at Deshpande Family Clinic runs a two-doctor practice in Pune and is the reason we built per-doctor queue isolation — because his setup broke every assumption I'd made about single-doctor clinics.
"Every clinic that joins during early access has a direct line. What you need is what gets built next. That is not a marketing line. It is how the product has been built so far."
We are not at scale. We are not everywhere. We are at the stage where the clinics that join shape what the platform becomes — and that is, deliberately, where we are. The features that exist today exist because clinic partners needed them. The features that come next will be the same.
If you run a clinic that is held together by habit, paper, and the patience of a very good front desk team — this was built for you. Not by someone who studied your industry. By someone who spent mornings in it, and couldn't stop thinking about what it could look like if the tools matched the people using them.
We're still building. Come join us.