In 2021, I wanted to experience the raw, chaotic energy of an early-stage startup. I wanted to understand the ecosystem, the culture, and the sheer grit it takes to build a product completely from the ground up. That drive led me to Bima Garage, an insurtech startup based in Mumbai, India.
While the company had multiple verticals, I was embedded in the B2B engineering team. Our mission was to build a robust platform that bridged a massive gap: connecting agents stationed physically inside hospitals with back-office operators managing the labyrinth of insurance claims.
Here is a deep dive into the engineering challenges we faced, the tech we deployed, and how we solved real-world healthcare financing problems.
The Problem: A Broken Healthcare Financing System
Insurance penetration in India is notoriously low. To make matters worse, a large segment of the insured population has low credit scores. When a medical emergency strikes, people are often forced to take on predatory loans just to get admitted.
Even if you have good insurance, the companies are notorious for their claim processes. Claims are frequently delayed, aggressively negotiated down, or outright rejected exactly when the patient is most vulnerable.
The Solution: The Bima Garage Ecosystem
The business model was designed to absorb this headache. For a one-time processing fee (or a yearly subscription), Bima Garage takes over the entire claim process.
To understand the engineering requirements, you have to look at the two primary user journeys on the hospital floor:
- Scenario A (The Insured Patient): You have an accident and rush to the hospital. You are in no condition to navigate paperwork. Our partnered agents, stationed right at the hospital, use our platform to onboard you. From that moment, the back-office team takes over the entire headache of battling the insurance company for your claim.
- Scenario B (The Uninsured Patient): You rush to the hospital but have no insurance (or your claim is denied). The hospital agent onboards you into our system. Bima Garage (acting as an NBFC - Non-Banking Financial Company) steps in to finance the hospital bill directly. You then pay back the amount in simple EMIs at a nominal interest rate.
The Architecture & Tech Stack
To support this, we needed an architecture built for high availability and low maintenance.
- Core Backend: Python & Django
- Frontend: React (Web) & React Native (HobNob App for Android/iOS)
- Database: PostgreSQL
- Infrastructure: Docker & Kubernetes (K8s)
The system featured multiple endpoints connecting our mobile app (HobNob) used by hospital agents, and our web portal (Desk) used by the back-office. When a customer was onboarded, the system required only minimal data points and a unique identifier (like a Mobile Number or National ID) to track the entire lifecycle of the case.
During my tenure, we built several critical features to make this engine run. Here are the highlights.
1. The Credit Scoring & Financing Engine
When an uninsured patient (Scenario B) needed immediate financing, time was critical.
Once onboarded, our platform automatically reached out to secure third-party vendors to fetch the patient’s CIBIL (credit) score. Using this data alongside the estimated medical costs, our internal scoring algorithm evaluated the risk. It then generated a recommendation for our banking partners on whether to approve the loan and at what interest rate.
Because patients and their families are highly anxious during this time, communication had to be instant. We built an event-driven notification system.
Every time a database row updated its status, a Django Signal fired. This handed the task off to a Celery background worker, which communicated with AWS SNS to blast out WhatsApp and Email updates.
2. Automating Repayment with eNACH
Financing a medical bill is only half the battle; collecting the EMIs reliably is the other half.
We initially evaluated standard payment gateways like Paytm and Razorpay. However, for recurring B2B invoicing and B2C loan repayments, we needed something that required absolutely zero human intervention month-over-month. We chose to integrate eNACH (Electronic National Automated Clearing House).
By having the user register a one-time eNACH mandate, our system was authorised to automatically pull the EMI amount directly from their bank account on a specific date. It also allowed us to pause or cancel the mandate dynamically via code if their repayment plan changed.
High-Level Design (HLD) for eNACH Flow:
3. Hacking Turnaround Time (TAT) with Email Automation For a long time, our biggest operational bottleneck was manual claim tracking. Back-office employees had to constantly refresh portals and check inboxes for status updates from the Insurance Companies. This resulted in massive Turnaround Times (TAT).
Guided by a senior Solution Architect, we built a clever workaround: The Email Polling Engine.
We set up scheduled cron jobs in our task queues that constantly polled our dedicated claims inboxes. Using Python’s scraping libraries and email parsing techniques, we created scripts that could “read” the automated emails sent by various insurance companies. The script would extract the claim ID, identify the status (e.g., “Query Raised”, “Approved”, “Rejected”), and automatically update our PostgreSQL database.
What used to take hours of manual data entry was reduced to seconds, triggering an immediate chain reaction of notifications to the hospital desk.
4. Condensing Chaos: OCR and KYP (Know Your Policy)
I was handed this feature on incredibly short notice. The concept was brilliant: Insurance policy documents are generally 20 to 40 pages of dense, unreadable legal jargon. We wanted to build a feature that condensed this into a simple, 1-page KYP (Know Your Policy) summary.
To extract text from massive PDFs, we tested everything: Python’s native Tesseract, AWS Textract, and Google Cloud Vision. Ultimately, Azure Form Recognizer ticked all the boxes for speed and accuracy on unstructured Indian financial documents.
However, processing a 40-page PDF is computationally heavy. If five users uploaded policies simultaneously, it could lock up our main Django threads and crash the API.
The RabbitMQ Solution: To protect our infrastructure, we decoupled the processing. When a user uploaded a policy, the file went straight to an AWS S3 bucket, and a message was dropped into a RabbitMQ queue. The user immediately got a “Processing...” screen.
In the background, dedicated worker nodes consumed the RabbitMQ messages one by one, sent the PDFs to Azure, parsed the returned JSON, generated the 1-page summary, and alerted the user when it was done. We consistently delivered the KYP document in under 5 minutes without ever overwhelming our core servers.
Final Thoughts
Engineering at a startup teaches you that code isn’t just about syntax; it’s about solving actual, painful problems. There will always be brilliant ideas floating around, but the idea itself is cheap. It is the execution how you design the database, how you handle the queues, and how you manage the edge cases that actually matters.
Till next time, happy coding.
