wm2.dev
appKitFeatured

App-Kit

Multi-tenant SaaS platform: build Telegram bots, mini-apps and sites from pluggable modules.

Author & lead engineer
backendpaymentsfrontend

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.