Hastle Free · multi-tenant telematics backend

Onboarding a partner means writing config. Not code

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.

16 settingsNot lines of code
2 kinds of programsInsurance pricing & consumer apps, live today
1 backendRuns every partner
A second signatureRequired before anything risky ships
Talk to an engineer → Watch it flip →
See it happen

Flip one switch. Watch a whole program reconfigure

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.

hastlefree.internal / tenants / sdk_pilotinsurance_platform / config
Trip detection & scoring Always on
Self-registration OnOff
Scoring dashboard OnOff
Policy management OnOff
Webhooks & CRM integration OnOff
Pricing model
Usage-based (km) Behavior-based (score)

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.

Not just this page’s word for it
“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
Where this came from

Built from the forks that shouldn’t have existed

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.

0Per-partner forks in the codebase
ConfigWhere coverage rules and handicaps live instead
What this solves

What breaks first, once the program’s actually live?

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.

Every telematics program hits the same wall in month two

Before anyone writes a single underwriting rule, three things have to already be true. We already hit that wall, building this. You don’t have to.

  • Tenant isolation — one partner’s config can’t leak into another’s data or rules.
  • A safe way to change the rules — without a redeploy, and without breaking the tenants who didn’t ask for the change.
  • A pipe that never drops a trip — trip data keeps flowing even when a partner’s system is slow, down, or sends something broken; we retry until it lands.
Weeks, not a hiring cycle Config, not headcount

Change a rule without opening a ticket

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.

No engineering sprint A second signature on anything risky

Price by the kilometer, or price by the driver

Same tenant, same backend — a setting flipped, not a new sales cycle for a new product.

usage_based / behavior_based One tenant, either model

A driver disputes their score on a Friday evening

Support pulls up the trace, sees exactly what happened, and answers — before anyone has to page an engineer.

One trace per dispatch Support self-serves
How we ship

Isolation and config safety first. Everything else, in order

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.

Gradual, on purpose

The move to faster trip processing rolls out one customer at a time

Trip and policy processing are both moving to a faster system today — turned on gradually, one tenant at a time, not switched on for everyone at once. The older system stays running as a proven fallback until the new one has earned its retirement.

Why it matters: a migration with a fallback is a plan. A migration without one is a bet, on your data.

Retired, not rewritten

We retired the old /drivers/ connection instead of keeping it alive forever

Every partner now runs entirely on one current API. No old version left running quietly on the chance someone’s still using it — we checked who was, then removed it.

Why it matters: a codebase that can delete things is a codebase you can trust to add things.

Sequenced, not skipped

Billing and tenant-offboarding tooling are next — deliberately after isolation

Usage-metering, billing, and the tools to suspend or export a tenant’s data are on the roadmap, not in production yet. We built strict per-tenant data separation and a two-person approval process for config changes 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.

FAQ

Questions, answered

What is Hastle Free?
A backend that runs usage-based and behavior-based insurance programs and SDK pilots like Bodha Drive from a single codebase — each partner’s data walled off from every other partner’s, with onboarding done through configuration instead of custom code.
Does onboarding a new partner require new code?
No. Onboarding means writing configuration — feature flags, coverage rules, ways to connect their existing systems — not forking the codebase. Each partner’s data lives in its own separate, walled-off database.
Can I self-host Hastle Free?
Yes, where a program needs it — see Data Residency for how self-hosted and regionally pinned deployments work.
Does Hastle Free power Bodha Drive?
Yes. Bodha Drive runs on the same Hastle Free backend as our insurance customers — its own walled-off partner, right alongside the usage-based and behavior-based insurance programs running there.
See all FAQs →
Talk to an engineer

Ready to see this running on your rules?

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 call →