App-Kit
Multi-tenant SaaS platform: build Telegram bots, mini-apps and sites from pluggable modules.
01 Problem
A single tenant owns projects, sites and modules; every business (shop, booking, CMS, reviews) wanted its own data, roles and integrations without forking the codebase. The platform needed strict per-site isolation and a way to swap an integration for an in-house service without touching feature code.
02 What I built
A Django + DRF backend with a Project → Site → Modules tenancy model. Features ship as pluggable modules (shop/orders, booking, CMS, FAQ, reviews, pricing, loyalty, newsletter), and every external dependency sits behind an ABC + factory adapter (payments, telegram, storage, image, notifications, auth) chosen per site by config. Per-site RBAC lets an owner define custom roles and a granted/denied permission matrix; auth supports both JWT for admins and Telegram HMAC for mini-app clients. Three Next.js frontends — client-admin, platform-admin and a public storefront — consume the same API.
- Project → Site → Modules multi-tenant model with strict per-site data isolation
- Features as pluggable modules; external services behind ABC + factory adapters, chosen per site
- Per-site RBAC: owner-defined roles + granted/denied permission matrix, auto-seeded from modules
- Dual auth — JWT for admins, Telegram HMAC for mini-app clients; three Next.js frontends on one API
03 Result
A new business stands up on shared infrastructure with its own isolated data, roles and modules; swapping an integration is a config change, not a rewrite. The architecture is captured across a large set of ADRs so the reasoning behind tenancy, adapters and auth is durable.