Small team, long memory.
Sammati is built by a deliberately small group in Bangalore — domain people who have carried the obligation themselves, engineers who treat a consent record as a legal instrument, and counsel who read every notice before it ships.
Four disciplines, one product
Domain
People who have sat on the obligated side of the table.
Healthcare is where this platform cut its teeth, and it shows in the parts other tools skip: correction by amendment rather than overwrite, medical-record retention that outlives a consent withdrawal, and §9 parental consent for paediatric records. Sector depth is why the product argues with you about retention defaults instead of accepting whatever you type.
Engineering
The ledger, the platform, and the infrastructure under both.
One codebase serving SaaS and customer-cloud deployments, a hash-chained consent ledger with integrity verification that runs on a schedule rather than on request, Postgres row-level security enforced per tenant, and a consent write path held to a sub-200ms p95. The test suite is large and unglamorous because the alternative is finding out in production.
Legal & content
Everything a data principal actually reads, reviewed by counsel.
Purpose definitions, lawful-basis defaults, notice templates and the twenty-two language translations are drafted in-house and signed off with our partner law firm before they ship as a purpose pack. We do not give legal advice; we ship content a lawyer has already been through, and we tell you which one of those two things you are getting.
Delivery & support
The same people who build it are the ones you reach.
Implementation, migration of existing consent records, and support all run through the team that wrote the code. There is no tier-one script standing between a question and someone who can answer it. That does not scale forever, and we will say so plainly when it stops.
Three habits that show up in the product
- 01
Small on purpose, for now
We cap how much work we take on rather than hiring ahead of it. A consent platform that ships late is a compliance risk we have handed to a customer, so capacity is the constraint we manage first and the number we quote honestly on a sales call.
- 02
Written before built
Product requirements, threat models and decision records live in the repository next to the code they govern. When someone asks why a thing works the way it does, the answer is a document with a date on it.
- 03
We do not ship claims we cannot evidence
Uptime, latency, language coverage and integrity guarantees on this site map to something measurable in the platform. Where a capability is early, the feature list says so rather than rounding it up.
You'll talk to the people who built it.
Book a demo and the call is with the team, not a qualifying layer in front of it.
Want to join? See careers.