Planned architecture
How Qeet People is built — a Kotlin/Spring Boot backend on the Qeet platform, API-first, sharing identity with Qeet ID.
Phase 0 — foundation in place
The Qeet People backend is at its Phase 0 foundation: a Kotlin/Spring Boot modular-monolith skeleton with multi-tenant Row-Level Security and Qeet ID OIDC wiring. No HCM domain logic ships yet; this page describes the intended architecture from the technical design, and specifics may change.
Platform foundation
Qeet People is built as a Kotlin / Spring Boot backend (modular monolith) on the shared
Qeet platform — the JVM is chosen so the India statutory payroll engine can use the official
EPFO/ESIC/TRACES libraries and BigDecimal precision. Rather than standing up its own
identity, tenancy, and audit, it builds on Qeet ID: authentication, RBAC,
multi-tenancy, and the tamper-evident audit trail come from the identity layer.
Identity graph
People and Qeet ID share one identity graph. An employee record is associated with a Qeet ID user, so there is no cross-system sync — lifecycle changes in People drive ID provisioning directly.
API-first
The product is API-first: every capability is exposed over a REST API described by an OpenAPI spec, with typed SDKs and webhooks — the same developer model as the rest of the Qeet suite. Application docs and SDK references will land here as the API stabilizes.
India-first HCM
The architecture accounts for India statutory needs (PF, ESI, PT, TDS) and regional-language support as core requirements, not add-ons — see the roadmap for sequencing.
What exists today
A Phase 0 foundation — a Kotlin/Spring Boot modular-monolith skeleton with multi-tenant Row-Level Security and Qeet ID OIDC wiring, plus two frontend shells (admin + ESS/MSS) — and the product/technical design. There are no HCM domain endpoints or SDKs yet; follow the changelog for the first shipped milestones.