Multi-Tenant SaaS for Compliance Tracking
The client was an enterprise compliance services firm that managed regulatory obligations on behalf of multinational customers across employment law, data protection, anti-money-laundering, and industry-specific frameworks. Their existing service model relied on per-region offices, each running its own tracking spreadsheets and email-based escalation workflows. As customers consolidated regions under single compliance officers, the lack of a unified platform was becoming a sales liability — customers wanted one view of obligations across countries and the firm could not deliver it.
Productivity & SaaS Tools
LegalTech, Enterprise SaaS
16 weeks from kickoff to all regions migrated and general availability
5 specialists
The full story
The practical problem was that compliance obligations differed by jurisdiction, by industry, and by the customer’s own operating footprint, and they changed continuously as regulators issued updates. A general-purpose project management tool could track tasks but could not model the structure of compliance — obligations with deadlines, evidence requirements, reviewers, and audit trails. Each regional office had built workarounds that worked locally but did not aggregate, leaving customers with no group-level view.
We built a multi-tenant SaaS platform with a unified compliance data model that handled obligations, evidence, reviewers, and audit trails across regions, with per-tenant data residency to satisfy cross-region data-handling requirements. The platform exposed a multi-language interface for customers operating across linguistic boundaries, automated alert workflows tied to obligation deadlines, and group-level dashboards that aggregated across regions without violating data-residency constraints by relying on derived metrics rather than raw data movement.
What shipped was a customer-facing platform where a group compliance officer could see every obligation across every region in one view, drill into specific jurisdictions for detail, and receive automated alerts ahead of deadlines. Each regional office worked in its own data residency while contributing to the group view, and the firm shifted its delivery model from per-region service to platform-plus-advisory. The cost of compliance tracking dropped for customers, the firm’s sales team won deals against larger competitors specifically on the group-view capability, and the regional offices reduced low-value coordination work in favor of higher-value advisory.
Customers consolidated under group compliance officers but the firm could not give them a unified view across regions.
Per-region offices ran independent tracking with spreadsheets and email, producing no aggregation up to the group compliance officer.
General-purpose project tools could track tasks but did not model obligations, evidence, reviewers, and audit trails together.
Cross-region data residency rules prevented simply consolidating data, which had blocked prior unification attempts.
Multi-language requirements across customer operating footprints were not supported by existing tracking workflows.
Without a group-level view, the firm was losing competitive deals against larger competitors who had platform offerings.
How we structured the engagement
Modeled compliance as a structured domain with per-tenant residency, then aggregated via derived metrics to respect data rules.
- 01Phase 01Weeks 1-3
Discovery
Audited workflows across four regional offices, taxonomized obligation types and evidence requirements, and worked with the firm’s legal team on data-residency constraints per jurisdiction. Output: a compliance domain model, a per-tenant residency specification, and an aggregation strategy that moved derived metrics rather than raw data.
- 02Phase 02Weeks 4-5
Architecture
Designed a multi-tenant data model with per-tenant database routing by residency, a shared application layer, and an aggregation service that read derived metrics across residency boundaries without moving raw obligation or evidence data. Used FastAPI for the application layer and Postgres per residency cluster.
- 03Phase 03Weeks 6-13
Build
Shipped the obligation data model and the residency routing first, then the evidence handling and reviewer workflow, then the alerting and the group dashboards. Implemented the multi-language interface with translation memory tied to the obligation taxonomy so terminology stayed consistent across languages within each obligation type.
- 04Phase 04Weeks 14-16
Launch
Migrated one regional office at a time onto the platform across six weeks, with parallel-running spreadsheets during each region’s first two weeks for safety. Onboarded three pilot customers in the same period for the group dashboard. Promoted to general availability after the third customer signed off on the group view.
What we built, component by component
- 01
Obligation data model
Structured representation of obligations, deadlines, evidence requirements, reviewers, and audit trails across jurisdictions.
- 02
Per-tenant residency router
Routes tenant data to the appropriate residency cluster based on jurisdiction rules, enforced at the application layer.
- 03
Evidence handling
Per-obligation evidence attachment with versioning, reviewer assignment, and audit-trail capture for compliance verification.
- 04
Alerting engine
Deadline-driven alerts with escalation paths configurable per obligation type and reviewer role, with audit logging per fire.
- 05
Aggregation service
Reads derived metrics across residency clusters to produce group-level views without moving raw data across boundaries.
- 06
Multi-language interface
Translation memory tied to obligation taxonomy so the same obligation reads consistently across languages within each tenant.
Obligations live in per-residency clusters with evidence, reviewers, and audit trails kept local. The alerting engine fires within each cluster based on local deadlines, and the aggregation service reads derived metrics across clusters to compose the group-level dashboard without crossing data-residency boundaries. The multi-language interface renders the same data in the reviewer’s preferred language with consistent terminology.
The trade-offs we made and why
Per-tenant residency with derived-metric aggregation, not central data
Centralizing data would have produced a cleaner architecture and a non-starter sales conversation with European and APAC customers. Per-residency clusters with derived-metric aggregation gave customers the group view they wanted while keeping raw data inside the required jurisdiction.
Modeled compliance as a structured domain, not as tasks
Treating obligations as generic tasks would have lost the structure that made compliance defensible — evidence, reviewers, audit trail. A structured domain model produced first-class entities the platform could reason about, which is what made the alerting and the audit story work.
Translation memory tied to obligation taxonomy
Free translation produced inconsistent terminology across languages, which compliance reviewers found unreliable. Tying translation memory to the obligation taxonomy meant the same obligation read with the same vocabulary across languages within each tenant, which preserved reviewer trust.
Migrated regional offices one at a time with parallel-running
A simultaneous cutover across all regional offices would have created risk that no compliance customer would tolerate. Migrating one region at a time with two weeks of parallel-running spreadsheets gave us recovery options and built confidence with each region before the next.
What changed for the client
tracking cost
Reduction in customer-side compliance tracking spend across the pilot cohort over the first six months after rollout.
cross-region data moves
Raw obligation and evidence data stays within its residency cluster, with aggregation via derived metrics only.
unified view
Group compliance officers get one view across all regions, with drill-down into per-region detail respecting residency rules.
languages supported
Languages live at launch with translation memory tied to obligation taxonomy for terminology consistency across reviewers.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
Residency as architecture rather than configuration was the decision that earned the customer base. Treating data residency as a deployment-time concern would have left us with a system that customers’ procurement teams could not approve. Building residency into the data model from day one made every subsequent feature compatible by default.
Modeling compliance as a structured domain unlocked everything downstream. A task-based approach would have left the platform indistinguishable from generic project tools, which is exactly what customers were already using and finding insufficient. The domain model was the moat.
Translation memory tied to taxonomy was the small decision that produced outsized reviewer trust. Free translation would have produced subtle inconsistencies that compliance reviewers caught immediately. We would invest in terminology-controlled translation on any compliance or legal product in the future.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
Patterns for AI features, internal tooling, and product delivery in SaaS businesses.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy