MEDmin

InspirationThe idea for MEDmin came from a very ordinary, very frustrating moment: a family member needed an antibiotic at 11 PM, and the nearest 24-hour pharmacy was a 20-minute drive away — while a small chemist shop two streets away almost certainly had it in stock, just not online. We started asking around and realized this wasn't a one-off. Most e-pharmacy apps in India route every order through a centralized warehouse, even when a local chemist could fulfill it in minutes. For someone managing a fever at midnight, or an elderly parent who's run out of a heart medication, "next-day delivery" isn't good enough.

That gap — between medicine that already exists nearby and medicine that actually reaches you in time — is what MEDmin exists to close. We wanted to build something that treats "minutes" not as a marketing word, but as an actual service-level promise, especially for the people who need it most: elderly patients living alone, chronic-illness patients on recurring prescriptions, and caregivers trying to look after a parent from a different city.

What it does What We Learned

Going in, we assumed the hardest problem would be logistics — routing riders efficiently. It turned out the harder and more interesting problem was trust and verification:

Prescriptions are messy. Doctor's handwriting is famously illegible, and building something that could reliably read it (or gracefully fail and ask the customer instead of guessing) taught us a lot about the limits of OCR and where human-in-the-loop design actually matters more than raw model accuracy. Healthcare regulation is not a footnote — it's core product design. We spent real time in India's Drugs & Cosmetics Act, 1940, e-pharmacy draft rules, and the IT Act, 2000, to understand the legal difference between an "inventory model" (owns stock, needs a drug license) and a "marketplace model" (pure technology facilitator). That research directly shaped our zero-inventory architecture — it's not just a cost decision, it's the difference between a viable business and a regulatory nightmare. "AI-powered" is easy to say and hard to earn. We learned that for anything touching a prescription, AI confidence has to be a first-class product signal, not an implementation detail — which is why double-verification became central to the design rather than an afterthought. How We Built It

We designed MEDmin around one core architectural decision: MEDmin owns no inventory. It's a technology layer that connects customers to independently licensed, verified local pharmacies — which meant our entire build was about matching, verification, and real-time state, not supply chain.

Order flow:

Customer → photo/search AI OCR → match Nearest Pharmacy (live stock) → dispatch Rider → GPS Delivery Customer photo/search

AI OCR match

Nearest Pharmacy (live stock) dispatch

Rider GPS

Delivery

Stack:

Client apps: React Native, with three distinct experiences — customer, delivery rider, and partner pharmacy — sharing a common backend but very different UX needs (a rider needs a map and a queue; a pharmacy needs an inventory dashboard). Backend: Node.js with PostgreSQL, chosen for straightforward relational modeling of orders, pharmacy stock, and verification states. Live tracking: Google Maps API for real-time rider location. Prescription reading: a custom OCR + handwriting-recognition pipeline trained on prescription-style data, with a confidence threshold — below it, the system asks the customer to type the medicine name instead of guessing.

The double-verification loop was the piece we cared about most: every prescription passes AI pre-screening first, but a licensed pharmacist always gives manual sign-off before dispatch. The AI is a speed layer, never an approval authority.

We also built the Emergency SOS mode as a distinct fast-path in the order flow — one tap that skips standard matching heuristics and auto-prioritizes purely by nearest available stock and fastest rider, because in a genuine emergency, every extra decision point costs time.

Challenges We Faced Handwriting recognition on real-world prescriptions. Doctors' handwriting varies wildly, and a model that's "pretty good" is dangerous in a medical context — a misread drug name is not an acceptable failure mode. We had to design for graceful degradation (falling back to manual entry) rather than chasing marginal accuracy gains. Balancing speed with safety. Every feature we added to make delivery faster — auto-prioritization, live stock matching, one-tap SOS — had to be weighed against not skipping the pharmacist verification step. Speed and safety kept pulling in opposite directions, and most of our design debates were really about where to draw that line. Designing for a regulatory gray zone. India's e-pharmacy rules are still evolving, and we had to build a product whose architecture itself is the compliance strategy — structuring MEDmin strictly as a marketplace intermediary rather than trying to bolt on legal compliance after the fact. Cold-chain medicines. Insulin, vaccines, and other temperature-sensitive drugs don't fit neatly into a "any nearby rider" delivery model. We had to design for insulated transport and rider training as a distinct delivery class, not treat all medicines identically. Two-sided marketplace cold start. Like any marketplace, MEDmin only works if there's both pharmacy supply and customer demand from day one in a given area — which pushed us toward a hyperlocal, neighborhood-by-neighborhood rollout strategy rather than a broad simultaneous launch.