Skip to main content
Release
v1.0.0

v1.0 — Multi-tenancy: from prototype to platform

A real Django backend, schema-isolated tenants, embeddable widgets, feature flags, and role-based access. The architectural boundary between proof-of-concept and SaaS.

  • #multi-tenancy
  • #platform
  • #rbac
  • #widget

v1.0 is the version where this stopped being a prototype. A real Django backend launched, every organization got its own isolated data store, and the product became something we could sell to multiple companies at once.

What shipped

  • Multi-tenant Django backendlm-multi-tenant service with PostgreSQL schema isolation per organization. Customer data is physically separated, not just logically tagged.
  • Embeddable widget — drop Curated into any existing site or app via a JS snippet. Per-widget configuration (theme, scope, capability flags) so the same product can present as a partner's tool.
  • Feature flag system — release features per organization without code branches
  • Role-based access control — three roles to start: superadmin, admin, user. Each scoped to what they can see and do.
  • OpenTelemetry observability — distributed traces across the three services so when something is slow, we know which span is to blame

Why it mattered

Before v1.0, every customer would have meant a new deployment or a manual data carve-out. After v1.0, onboarding a new organization is a row in a database. This was the architectural prerequisite for everything since: SSO, billing, the rebrand to a commercial product. None of it works without isolated tenants.

If you're an admin, this is also when the Settings → Workspace surface first became meaningful — there's now an "organization" to settings about.