AML SoftServe360 — Multi-tenant Compliance SaaS Platform
Platform & tenancy model
Designed organization-scoped isolation end-to-end: requests resolve an organization context, domain logic stays framework-agnostic, and Postgres Row Level Security backs data access. Migrations are versioned with the Supabase CLI so schema changes remain reviewable and reproducible across dev, QA, and production.
Engineering pillars
- Server components by default with clear server/client boundaries
- API versioning under /api/v1 with consistent validation
- Zustand for lightweight UI state where client interactivity is required
- Centralized TypeScript types and generated DB types from Supabase
- Docker multi-stage builds for predictable deployments
01 Background
AML programs depend on systems that are secure, traceable, and able to grow with new regulations and integrations. The goal was not a demo dashboard but a credible SaaS core: real auth, real multi-tenancy, and a path to scale features (queues, webhooks, reporting) without rewriting foundations.
TechCirkle aligned engineering practices with the product brief: SQL-first schema design, explicit tenancy rules, and operational tooling (local Supabase, seed data per environment) so future contributors can ship safely.
02 The challenges
Multi-tenant SaaS fails when tenancy is bolted on late. The team had to enforce organization isolation at the database and API layers, keep latency acceptable for interactive flows, and avoid leaking identifiers across tenants in logs, errors, and admin tooling.
AML-style products also imply stricter expectations around audit trails, least-privilege access, and change control. The architecture needed to make the right thing the default—without blocking product velocity.
Key Challenges:
- Tenant isolation with RLS and consistent org context on every request
- Balancing flexibility (feature flags, extensibility) with strict data boundaries
- Operational complexity: migrations, seeds, and environment parity
- Preparing for async work (webhooks, jobs) without blocking the MVP surface
03 The solution
Implemented SoftServe360 as a Next.js + Supabase platform with organization-scoped data access, versioned SQL migrations, and API handlers that validate session and organization context before executing domain logic. The stack emphasizes server-first rendering, typed data access, and clear module boundaries between routes, domain, and persistence.
Delivery included developer ergonomics: scripts for local database lifecycle, type generation from the schema, and documentation for architecture and API conventions—so onboarding stays fast as the team grows.
Why Next.js & Supabase (instead of a bespoke backend only)
The product needed rapid iteration with production-grade data guarantees. This pairing was chosen for concrete engineering reasons:
Postgres as the system of record
RLS and constraints enforce tenant boundaries where it matters; migrations stay reviewable and auditable.
Auth + data in one platform
Supabase Auth integrates with the same database policies, reducing glue code and mismatch bugs.
Next.js App Router fit
Server components and route handlers map cleanly to SSR, secure data loading, and versioned APIs.
Operational path to scale
Dockerized builds, environment templates, and Supabase tooling support dev/QA/prod workflows without custom infra sprawl.
Project Highlights
Discovery & threat modeling (product + engineering)
Mapped core user journeys, tenant lifecycle, and minimum viable security controls. Agreed on non-negotiables: org isolation, auditable schema changes, and explicit API contracts for future integrations.
Schema, tenancy, and migrations
Modeled organizations and membership, applied RLS policies, and established migration discipline with Supabase CLI—so tenant rules live with the schema, not scattered in app-only checks.
API surface (/api/v1) & validation
Defined consistent request validation patterns and error shapes. Ensured handlers always resolve organization context before touching domain services.
Frontend experience & performance
Built UI with Tailwind + shadcn patterns where appropriate, favoring server rendering and small client islands for interactivity to keep bundles lean.
Hardening, QA, and handoff
Added practical guardrails: logging discipline, seed datasets for local QA, and documentation for runbooks—so the platform is ready for continuous delivery as AML features expand.
Outcomes & benefits
Credible SaaS foundation
A multi-tenant core that can grow AML features without re-architecting tenancy or auth.
Faster, safer iteration
SQL-first migrations and generated types reduce schema drift and runtime surprises.
Clear extension points
Versioned APIs and domain boundaries make integrations and background jobs tractable.
Operational readiness
Docker + documented workflows support predictable builds and environment parity.