Four products. One set of non-negotiables.
Sumeru Systems builds AI-native business software: Commerce OS and Searchlight for Shopify commerce, Vaani for enterprise voice AI, HRMS for people operations. They do not share a codebase, and we are not going to tell you they do - what they share is a set of things each one has to have before it ships.
Not one platform. One standard, four times over.
Most multi-product companies claim a shared platform they do not have, and the claim survives until a buyer's engineer goes looking. Ours is the opposite claim: these are separate systems that each had to earn the same four primitives before they were allowed to ship. Every entry below is countable in the product it describes.
| Non-negotiable | Commerce OS + Searchlight | Vaani | HRMS |
|---|---|---|---|
| Tenant isolation enforced, not documented | Schema-level scoping on every query, plus a CI lint rule that rejects reads which don't verify tenancy | Per-tenant model with a row-level-security integration test in the suite | Tenant scoping across the schema — 503 tenant-scoped columns over 51 migrations |
| Audit trail on every privileged action | Plain-language audit row per autonomous action, 365-day default retention, parent-child trace correlation | Append-only audit log with CSV export for compliance | Audit-log tables wired into privileged operations |
| Fine-grained access control per action, not per app | 145 named permissions across 17 engine namespaces | RBAC on every privileged action, SAML SSO on enterprise | Roles, user-role assignment and field-level permissions |
| Governed AI spend budgeted at the helper, not the route | Provider calls self-throttle and enforce per-shop budgets below the route layer, so no endpoint can bypass them | Per-tenant budgets, wallet and ledger cost attribution, a quote endpoint that prices a job before it runs | AI assistant scoped to the same role model as the rest of the product |
A shared kernel is the right end state and the wrong starting point. Extracting one before three products have shown you which parts genuinely generalise produces an abstraction shaped by guesses, and every product then pays for it. So each product owns its stack today, the primitives above are re-implemented deliberately rather than inherited, and convergence happens when the duplication has told us what to converge on.
You review the product you are buying. Nothing is inherited, so nothing is assumed — a control we claim for Vaani has to be true in Vaani. It also means no cross-product blast radius: a defect in one does not reach the others, because there is no shared runtime for it to travel through. Ask us to walk any row of that table in the architecture review; that is what the session is for.
How we build.
Infrastructure language, not app language
We sound like Stripe, Vercel, Datadog, Snowflake. Words like engine, platform, layer, orchestration, intelligence - used precisely, not as buzzword fog.
Specific over superlative
'Reduce attribution lag from 14 days to under 60 seconds' beats 'blazing-fast attribution.' Numbers, time intervals, named systems beat adjectives.
Show the system
Architecture diagrams, dataflow visualizations, dashboard screenshots carry more weight than hero illustrations. Buyers expect to see how it works.
Build for the operator, not the executive
The reader is a head of growth, agency principal, or platform engineer. They evaluate by architecture diagrams and integration depth, not by feature lists.
We're hiring.
Small team, high agency, deep technical work. We hire engineers who can read a system and operators who think like engineers.
No open roles yet. Pitch us anyway.
If you're interested in working on commerce infrastructure at this stage, send a note describing what you've shipped and what you'd want to ship here.