Case study · Veterinary SaaS
Alphaherd: a practice management system vets could actually use.
Indian veterinary clinics were running patient records, inventory and billing across disconnected tools: spreadsheets, WhatsApp threads and paper ledgers. Meanwhile India's pet care market was growing faster than the software built to serve it. As co-founder and founding designer, I led research with over 100 stakeholders and shipped a beta whose core flows we designed and tested with partner clinics, built around the work they do every day.
Founding Designer
The problem
One clinic, split across disconnected systems.
We found patient records in one place, inventory in another and billing in a third, usually a mix of notebooks, WhatsApp, spreadsheets and specialist software. With no shared source of truth, vets, front desk staff and owners each worked from a partial view of the same clinic.
Early observations · Payments
UPI sat outside the system.
We watched mid sized clinics run Western built software with no UPI support. Staff tracked each day's UPI payments by hand and reconciled them at closing.
Early observations · Inventory
Inventory features went unused.
Even where the software shipped inventory tools, we saw clinics skip them because logging was too tedious. Stock worth lakhs expired every month that distributors would have taken back if anyone had flagged it in time.
Vetbuddy, the practice management system most of the clinics we visited were already running, against Alphaherd, what we built. Drag to compare.
Discovery · Research
We did not just interview vets. We mapped how a clinic actually runs.
I designed the research protocol and ran it with more than 100 vets, clinic owners, store managers and operations staff across 85+ practices in Delhi NCR, Bengaluru and Guwahati. The sample ran from single vet practices, to mid sized clinics running three or four vets, to hospital chains with ten or more.
Segmentation
Choosing the first customer group
Small clinics, too early to sell to
Single vet practices ran on paper and personal WhatsApp, and had the least room in the budget for software. They taught us a great deal about daily habits, but the economics did not support building for them first.
Mid sized clinics, where we started
These clinics ran a patchwork of tools while actively trying to grow into larger practices. They needed help managing the day and growing revenue, and they could adopt a new system without an IT team of their own. We built for them.
Large clinics, already customised
Hospital chains often had technical teams and bespoke systems, which made an end to end replacement a much harder first sale.
Secondary research
19 competitors, and a clear gap in the middle.
I benchmarked 19 products, global and India based, to map the landscape, separate the must haves from the good to haves, and pinpoint where existing software was already failing Indian clinics. Five of them shaped our positioning most.
Vetbuddy (VetPort)
Our first battleTreated as the local industry standard, with an exclusive distribution deal through a large veterinary distributor. Around $75 per vet per month, and free for start-up clinics.
IDEXX
The major shareholderDeeply integrated with its own diagnostics hardware. It started pre-cloud aimed at small practices, and now orients to large corporate chains while acquiring rivals.
Vetic
The Indian challengerA pet care aggregator extending into clinic software across inventory, appointments and billing. It undercut on price and bundled clinic visibility into its own consumer marketplace.
Digitail
The one to beat long termThe fastest growing product in the category, with an $11M Series A, GDPR compliance and an explicit AI roadmap. Its pricing of $119 to $240 a month sat far above what Indian clinics would pay.
Shepherd
The user friendly oneSold on team morale and quality of life rather than feature count, which was the clearest proof that experience could be a viable wedge. Priced from $299 a month.
Competitive research · Pricing
We booked demos as buyers to find out what this market actually charges.
Ten companies, one protocol, so the answers lined up: pricing structure, hidden charges, discounts, data handling, migration, support hours, cancellation terms, integrations and roadmap.
Three were not veterinary products at all. They were Indian billing and inventory tools clinics already ran for the finance side, which made them the real competition for the modules we shipped first.
The per-seat rate is not published.
Products advertise a clinic price. What a practice actually pays climbs with every additional doctor and groomer on the roster, and none of the incumbents put that on the website. Clinics find out when they grow.
The real costs arrive after signature.
Data migration, storage above a small included tier, and training past the first few hours are all billed separately, and none of it is advertised. These were the quiet revenue streams holding the category up, and we had to decide whether to run the same play.
Two incompatible pricing logics.
Per-seat products, all of them selling internationally, against flat annual products selling only in India. More than a twentyfold spread for a similar claimed job. There was no neutral position to take.
Client communication is metered.
One product charges by message slab above a small free allowance. Another added a flat annual fee the day WhatsApp arrived. It was the feature clinics asked about most, and nobody bundled an allowance they could actually use.
Synthesis
Eight capabilities defined the benchmark needs of a veterinary practice
We landed on patient registration, electronic medical records, inventory, consultation notes, scheduling, client communication, billing and analytics. This became our map for what to build and in what order.
Prioritisation
Prioritising features
I ranked the eight capabilities against each other first, on how urgently a clinic needed them and how much of the day they swallowed. Finance, inventory and the client database came out on top.
Then I sorted individual features as must have, should have or can have, against whether each was a basic need, a satisfier or a delighter. That produced ten priority levels across finance, inventory, profiles, onboarding and the database, and a dated plan: internal testing by the end of July, beta through August alongside data migration, phase two by November, phase three by February.
From research to strategy
We did not design in a vacuum. We built alongside our first customers.
To test real customer intent fast, I led the entire MVP build, directing my co-founder and two junior designers. Research became fully prototyped, design system backed screens in three weeks. That level of polish and workflow detail is what convinced design partners to sign on, and a few clinics asked whether they could buy it on the spot.
I secured design partnerships with four clinics and one pet store chain across Bengaluru and Delhi NCR, and we built with them from day one. They gave a Letter of Intent to become a first customer and tested the beta as we built it. Getting a small group to love the product mattered more to us than moving fast alone.
The MVP · Prototypes
A clickable clinic, three weeks in.
We built the MVP in Figma around the critical workflows the research had surfaced. Both prototypes below are live, so you can click through them here.
The AI bet, designed but not shipped
Alpha and AI assisted notes were part of the vision. They did not make the beta.
Both concepts tested well in the MVP and were central to how we pitched Alphaherd. We kept them out of the beta build for a deliberate reason: our design partners had more urgent, unglamorous problems, like reconciling a day of payments and keeping stock current, and we chose to earn trust there first. Vet confidence in AI was still forming in 2022, with some clinics enthusiastic and others openly sceptical, and shipping it responsibly would have needed technical depth the founding team did not have.
Building with partners
Finance, inventory and the client database came first. That is where the pain was loudest.
With the core workflows validated, I set the build order, weighing what our design partners needed day to day against where we wanted to take the product: finance, inventory and billing first, then client onboarding and setup. These were the areas partners and interviewees flagged most urgently, and where the biggest daily friction lived.
We raised friends and family funding to build this first version, worked with a rotating team of about 11 developer interns from IIT Guwahati, and hosted the product on cloud infrastructure. Closest to the customers and the design, I owned product direction, research, workflow design and testing, while the development team owned technical architecture, implementation and hosting. That split kept each iteration anchored in problems prospective customers had told us mattered.
Testing with partners
Tested in the room where the work happens.
We tested each build directly with partner clinics before the next feature shipped, sitting in during live appointments and inventory shipment runs to see where the flow broke. Testing happened on the partners’ own machines, during their own working day: basic training, then quotas, a number of invoices daily and a purchase order weekly, everything running in parallel with the software they already paid for, entered into Alphaherd first and then into their existing system.
Double entry is a real cost to ask of a busy front desk. It was also the only honest way to see how the product held up under actual load without asking a clinic to bet its operations on unfinished software, and it gave us a like-for-like comparison against the incumbent on the same tasks.
Key flows
Client onboarding
Client onboarding meant a flow simple enough for a non technical admin to set up quickly, while still capturing everything the clinic needed. Admins could invite staff such as receptionists, vets and groomers by email for approval, and add branches for multi location practices. The prototype below shows these flows in action.
Connected finances, inventory and database
Every sale, purchase order and stock movement is tied together. A sales invoice automatically updates inventory, a purchase order tracks what is owed to the distributor until it is marked received, and expiring or low stock items surface before they become a write off.
What testing changed
The invoice, rebuilt around how the front desk actually works.
Invoicing was the most used screen in the product and the first one partners pushed back on. Four changes came out of watching receptionists work it under pressure.
Before · first build
After · partner testing
Discount moved onto the line.
It had been a nested row under each item, which is not how receptionists think about a discount. It became two columns on the item itself, percentage and amount, each updating the other, so the number goes in whichever way the clinic quotes it.
Services joined products.
Indian clinics bill consultations, grooming and surgery on the same invoice as medicine. The table became Items and Services, and the batch column became Batch Number or Provider, so a service carries the staff member who delivered it the way a product carries its batch.
Recording a payment stopped being a detour.
It used to be a button that opened a separate window where you then chose money in or money out. Now the panel sits on the invoice itself, with the party’s outstanding balance visible as you type, a receipt number, UPI among the payment modes and a flag for advances. Below it, a running ledger of what has been paid and what is still owed. Clinics run on advances and part payments, and none of that belonged on another screen.
Adding an item stopped needing a button.
The first empty row is there when the document opens, and typing a name creates the next one. A receptionist mid-queue should not have to ask the software for permission to start.
Outcome · Reflection
What we built, and what the work taught me.
The work travelled by word of mouth. An HR lead who had seen Alphaherd demoed at a clinic she previously worked at invited us to present at Supertails, and we also demoed to one of the directors of Ziggly, who also ran one of our design partner clinics. Neither converted, because both needed a fully built system inside a month and we were still building, but the invitations came from people who had used the product and remembered it.
We could not take Alphaherd forward in the end. What it gave me was the experience of working closely with real users across the entire journey, from first conversations to a beta that clinics tested and used, and wearing every hat along the way: product manager, designer, researcher, founder, accountant and sales rep, often in the same week.
Build a founding team as deliberately as the product.
My co-founder and I were both designers without deep technical backgrounds. That gap slowed us down and left us figuring out the technical side largely on our own. A technical co-founder early on would have moved things faster and let us make sharper bets sooner.
Treat data migration as an early requirement.
Clinic records lived across manual logs and other providers' systems, and pulling that data out proved harder than we expected. Clinics were reluctant to start over from scratch, and we had not designed for that reality early enough.
Weigh near term needs against future bets more deliberately.
Our AI driven ideas landed well with some clinics and met real scepticism from others, because trust in AI tools was still forming in this space. With more technical depth on the team we could have tested what was actually feasible, and aimed that thinking at larger customers who wanted it.
Sequencing a full end to end product is genuinely hard.
Clinics valued Alphaherd because it covered everything, but delivering on that took time, investment and a bigger team than we had. When we considered shipping a narrower first version of billing and inventory alone, it started to look like another point solution competing with tools clinics already used, which made it a harder sell than the full vision.
Building Alphaherd changed how I approach zero to one work. I treat adoption constraints as product requirements, stay close to users long enough to know which problems are worth solving, and build early and scrappy until I find the smallest entry point someone will actually pay for.
Get in touch
Happy to share more on this.
The design decisions, the research, or the founding journey.