CS-01 / Project dossier
Building a security-first React foundation for a multi-tenant product
How a founder-led, pre-production compliance product was shaped around explicit architecture boundaries, tenant isolation, reviewable AI, and evidence-based release gates.
- Confidentiality
- Anonymized case study
- Evidence status
- Approved evidence
CS-02 / Product context
Context
The product helps commercial property and facilities teams collect vendor compliance evidence, compare it with customer-defined requirements, and review the result. The planned workflow includes document submission, AI-assisted extraction, deterministic evaluation, human review, reminders, and an audit trail.
That combination creates a difficult frontend and product architecture problem. The interface must make dense evidence understandable without presenting AI output as fact. At the same time, organization data and private documents must remain isolated in a multi-tenant system.
Moussa led the product framing, React architecture, and implementation of the foundation.
CS-03 / Constraints
Constraints
The product was being built by a small, founder-led team, so operational complexity had to stay low.
Every organization needed a hard tenancy boundary across application logic, database access, and document storage.
AI output had to remain reviewable and untrusted until validated by a person.
External services needed replaceable seams so the domain was not coupled to one provider.
The architecture had to support a broad workflow without becoming a premature collection of microservices.
Progress needed to be demonstrated through repeatable engineering evidence, not an optimistic release label.
CS-04 / Architecture risks
The architecture risks
The largest risk was not an isolated React component. It was allowing product scope, tenant rules, provider integrations, and AI behavior to spread through the application without clear ownership.
That would make the UI harder to reason about, increase the cost of changing providers, and create opportunities for organization context to be lost between routes, actions, and database queries.
The second risk was trust. A compliance workflow cannot hide uncertainty behind a polished result screen. Original evidence, extracted values, deterministic checks, and human decisions need to stay distinguishable.
CS-05 / Decisions and trade-offs
Decisions and implementation
Keep one deployable application with internal boundaries
A modular monolith was selected: one Next.js application and one primary database, divided into explicit product modules. This kept deployment and local development manageable while preventing unrelated features from becoming one undifferentiated codebase.
The implemented foundation separates identity and access, organizations, vendors, and requirements. Shared platform and UI layers support those modules without owning their domain rules.
Point dependencies toward the domain
Business rules were kept behind application services and provider interfaces. Infrastructure adapters handle concerns such as persistence and external services.
This gives the product a practical replacement path when a vendor, storage mechanism, or extraction provider changes. It also makes the difference between domain decisions and framework plumbing visible during review.
Treat organization context as a security boundary
Organization membership is carried through authenticated application context and reinforced with database row-level security. Private storage is designed around the same boundary.
The frontend benefits from that explicit model: routes, server operations, navigation, and permissions can all be organized around the active organization instead of relying on incidental filtering.
Design AI as a suggestion layer
The architecture treats extracted AI data as untrusted input. Structured output must be validated, the original evidence must remain available, deterministic evaluation remains separate, and a person makes the final review decision.
This decision also shapes the interface. Review screens need to show evidence, confidence, exceptions, and human actions rather than collapsing the workflow into a single opaque score.
Build complete vertical slices on shared UI primitives
The working foundation includes organization and membership management, a vendor directory, and configurable requirements. These slices share an intentional design system instead of accumulating route-specific controls.
The approach tests architecture decisions against real product flows: authenticated navigation, organization-scoped data, forms, tables, validation, empty states, and responsive behavior.
Make release readiness evidence-based
Architecture constraints, static checks, database verification, accessibility scans, and build output were recorded as release evidence. A later readiness review kept production release blocked when hosted and independently reproducible corrective evidence was incomplete.
That distinction matters: a passing checkpoint is useful engineering evidence, but it is not the same thing as a production launch.
CS-06 / Documented checkpoint
Documented engineering checkpoint
At one recorded Sprint 04 checkpoint:
formatting, type checking, linting, and the production build passed;
the architecture report covered 123 modules and 287 dependencies with zero violations, plus two boundary tests;
207 unit, 38 component, and 49 database checks passed;
six unauthenticated accessibility scans reported zero automated accessibility violations.
These figures describe that documented checkpoint only. They are not customer results, ongoing service-level guarantees, or evidence that the product was production-ready. A subsequent readiness revision explicitly retained the production hold while additional hosted verification remained incomplete.
CS-07 / Result
Result
The work produced a coherent foundation for the next product slices:
- product domains have visible ownership and dependency rules;
- tenant isolation is part of the application and database model;
- organization, membership, vendor, and requirements flows exercise the architecture in working UI;
- AI-assisted behavior has explicit validation and human-review boundaries;
- external providers have defined seams rather than leaking into domain logic;
- release decisions can point to recorded evidence and unresolved gates.
The most important outcome is not a large feature count. It is a foundation where security, trust, and maintainability are treated as product behavior from the start.
CS-08 / What the work demonstrates
What this demonstrates
This engagement reflects the kind of work Moussa brings to difficult React products: turning ambiguous product risk into architecture decisions, building enough real workflow to test those decisions, and keeping release claims bounded by evidence.