HomeoAxis: from one clinic to a franchise-ready platform
A single-practitioner homeopathy practice needed to look and run like an institution, without losing the thing that made it work in the first place: accurate case matching.
What the clinic was dealing with
The practice ran on the founder's judgment and a manual booking process that didn't scale past one location. Growing into a chain meant two things had to hold up under expansion at once: the quality of patient-case matching, and the operational side of running several locations under one brand. Most platforms solve one of those problems and treat the other as an afterthought.
What got built
The core of the system is a rubricizer-first recommendation engine, built on an OOREP-based case corpus with Qdrant handling retrieval. That's the part that keeps case matching accurate as more practitioners and patients use the platform. Around it: WhatsApp-based patient engagement so booking and follow-up happen where patients already are, and Amazon SES for the transactional email load a growing clinic chain generates.
| Frontend | Next.js |
| Backend | Laravel |
| Database | PostgreSQL |
| Recommendation engine | Qdrant vector search, OOREP-based case corpus |
| Patient engagement | WhatsApp Business API |
| Transactional email | Amazon SES |
| Pricing architecture | Multi-tenant, Solo / Growth / Chain tiers by clinic count |
What changed for the business
A new clinic location can be onboarded through the pricing tier structure without touching core architecture — the bottleneck moved from engineering to sales.
Booking and follow-up moved from manual coordination to WhatsApp-native flows, cutting the friction between "wants an appointment" and "has one."
The practice now presents as an institutional chain rather than a single practitioner — the rebrand this platform was built to support.
Quantified figures are intentionally left out here pending the client's sign-off to publish them. Ask us directly for the numbers behind this case study.