One platform, behind
Tanvrit is one engineering platform: a shared Kotlin Multiplatform SDK, one API, and 6 native compile targets. The 9 products built on it are the proof that it works.
9 products. One codebase.
Each one stands on its own — its own brand, its own users, its own release train. Underneath, they draw on the same 25 SDK modules, the same authentication and storage layers, and the same API.
The engineering, in six parts.
Every number below can be re-derived from the source tree, and the command that produces it is recorded next to it in the codebase.
One codebase, six targets
The same Kotlin sources compile to Android, iOS, JVM desktop, WasmJS, JS and Linux — 6 targets in all. A bug fixed in the SDK is fixed everywhere at once.
25 SDK modules, 4 foundation modules
Auth, storage, networking, sync, commerce and UI are separate modules with published binary-compatibility checks. Products depend on what they need, not on a monolith.
One API behind every product
A single Ktor backend — 127 feature packages and 270 routers — serves all 9 products. Requests are tenant-scoped, so one app never reads another's data.
Offline-first storage
Reads come from a local SQLite store first. Writes queue in a sync ledger with retry and a dead-letter path, so a dropped connection delays a sync rather than losing a sale.
11,600+ automated tests
Counted across core, SDK and server. Lint, static analysis and a public-API surface check run on every push; a change that breaks the published ABI fails the build.
Encrypted where it matters
Identity fields are encrypted with AES-256-GCM before they reach the database, certificates are pinned in production, and data is served from asia-south1 (Mumbai).
Built for what you actually sell.
Onboarding branches by what a business sells — products, services, bookings, or a mix — so the catalog, the billing screen and the reports match the trade rather than a generic template.
Numbers you
can check.
The backend is a single Ktor 3.5.1 service on Google Cloud Run in asia-south1 (Mumbai), backed by MongoDB. Each figure below is stored with the command that produces it and the date it was last run — so when one goes stale, it is corrected in one place.
A short list, on purpose.
One language across client and server, one serialization format, one dependency-injection container. Fewer moving parts is the reason a small team can keep this many products current.
Kotlin Multiplatform
Compose Multiplatform
Ktor 3.5.1
MongoDB
kotlinx.serialization
Koin
WebSocket
Google Cloud Run — asia-south1 (Mumbai)