Hastle Free is the multi-tenant telematics backend underneath Sampark and Bodha Drive. Give it a new insurer’s rules, and it becomes a new program — not a new codebase. The same system already runs an insurance pricing program and a consumer app, side by side, without either one able to see so much as a row of the other’s data.
Don’t take our word for it — flip it yourself. This is the real shape of what changes when a tenant becomes an insurance program instead of a consumer app.
No new deploy. No new codebase. One tenant, one setting, a different program.
In plain terms: an SDK pilot like Bodha Drive gets self-registration and a scoring dashboard. An insurance program gets policy management, webhook and CRM integrations, and a choice between usage-based (per-kilometer) or behavior-based (per-score) pricing. Both run on the same trip-detection and scoring engine underneath.
“Sastram took over backend infrastructure end-to-end. The engineering judgment was a tier we don’t see often.”Ituran Group · on a separate engagement where Sastram took over their backend infrastructure end-to-end
Eight years running telematics programs across five markets taught Saunak the same lesson every time: sooner or later a partner needs something the platform doesn’t do yet — a per-policy kilometer deduction, a score-based handicap on premiums — and somebody forks the codebase to give it to them. Then somebody has to maintain that fork forever.
Hastle Free is what happens when you build the fix instead of living with the problem. One insurer deducts kilometers. Another applies a score handicap. Same codebase, same day it shipped. Partner #6 signing on doesn’t touch how partners #1 through #5 already run.
Not the pitch you get before launch — the problems that surface once policies are live, drivers are onboarded, and the first dispute lands on someone’s desk.
Tenant isolation. A safe way to change the rules. A pipe that never drops a trip. All of it, before anyone writes a single underwriting rule. We already hit that wall, building this. You don’t have to.
Coverage rules and scoring logic are edited directly by your product or actuarial team — not filed as a request and waited on. Anything that touches money still needs a second person to say yes.
Same tenant, same backend — a setting flipped, not a new sales cycle for a new product.
Support pulls up the trace, sees exactly what happened, and answers — before anyone has to page an engineer.
A backend that will hold policy and driver data earns trust in a specific order — isolate tenants, gate config changes, then layer in the rest. Here’s exactly where that build stands.
Trip and policy processing are both moving to a faster, non-blocking path today — behind a flag, one tenant at a time. We didn’t flip every tenant the day it shipped — the older path stays live as a proven fallback until the new one’s earned its retirement.
Why it matters: a migration with a fallback is a plan. A migration without one is a bet, on your data.
/drivers/ surface instead of maintaining it forever.Every consumer now runs entirely on one versioned API. No legacy branch quietly kept alive on the chance someone’s still calling it — we checked, then removed it.
Why it matters: a codebase that can delete things is a codebase you can trust to add things.
Usage-metering, billing, and tenant suspend/export are on the roadmap, not in production yet. We built schema isolation and the approval-gated config lifecycle first, because that’s what keeps live tenant data safe before a single line of billing code.
Why it matters: ask any vendor what they built first. The answer tells you what they actually value.
Bring your program’s rules. In 30 minutes we’ll tell you exactly which parts are already built — and which parts we’d actually have to build.
Book a 30-minute call →