The right SaaS architecture is the smallest system that preserves tenant boundaries, reliable business records, recoverable deployments and a credible path to scale.
This guide is part of the NexisHub Product Engineering desk. It connects practical engineering, research, and product decisions to the wider NexisHub platform.
The operating idea
NexisHub's reviewed web repository uses Next.js App Router, domain modules under src/lib, Prisma generation and feature-gated administration. This is evidence for how the company website is structured, not proof that every NexisHub product shares one deployed database or identity service.
An architecture decision begins with workload, team size, data sensitivity and failure consequences. A founder-led product may benefit from a modular application first, with queues and separate services added for measured reasons rather than prestige.
NexisHub separates verified platform documentation, repeatable observation, and inference. No optimization can guarantee selection or citation by an external system.
What the NexisHub implementation actually shows
The website separates public content, server routes, Prisma data access and administrative authorization in named modules. An administrator requires an authenticated session and verified authorization; a signed session alone does not grant every operation.
During its October 2026 Vercel investigation, NexisHub proved that a successful compilation could still fail during output packaging. The protected Preview later returned 200 for public routes while admin requests failed until a branch-specific NextAuth signing secret was configured. These incidents show why environment configuration, deploy outputs and safe denial behavior belong in an architecture review.
A decision table for a new SaaS
Choose a modular monolith when one small team owns the product, transactions cross related modules and the operational cost of service communication would exceed its benefits. Separate services may be justified by independently scaling compute, distinct trust boundaries, different teams or external integration isolation. These are tradeoffs, not maturity rankings.
For tenants, decide between a shared relational database with enforced tenant scoping and stronger physical separation. A tenant ID carried from a browser is not an authorization check. For long-running jobs, require idempotency keys, retry limits and recovery tests before selecting a queue. Search indexes and AI agent memories must not overwrite authoritative account or financial records.
Tests that decide whether the architecture is ready
Run fixture-based attempts to access another tenant's data, simultaneous writes, repeated webhook delivery and interrupted background work. Check that a previous failure can be explained using request IDs and that a rollback restores service without corrupting business state.
Write an architecture decision record containing the current team, expected workload as an assumption, data owners, security boundaries, deployment procedure, selected options, rejected alternatives and a review date. A microservice should be extracted after the specific pressure becomes demonstrable.
Core principles
- Preserve invariantsTenant access, billing states and authorizations must remain correct through retries and failures.
- Separate business truth from AI inferenceUse authoritative records for financial and permission decisions.
- Measure before extracting servicesNew service boundaries need an operational justification.
A practical implementation workflow
Apply the work in a controlled sequence. Keep a baseline, name an owner, and define the evidence that will show whether each step was completed.
- 1. Inventory roles and dataDefine tenant ownership, sensitive records and access tests.
- 2. Choose deployable boundariesUse a modular service where shared transaction integrity is needed.
- 3. Test the dangerous pathsExercise cross-tenant requests, duplicated events, retries and outages.
- 4. Document evolution triggersRecord evidence that would require more independent services.
Common mistakes
Premature distribution
More independently deployed components mean more failure and authentication boundaries.
Unverified tenant checks
A client-supplied tenant ID does not prove permission.
Build-only verification
The deployed runtime may still fail because of secrets or packaging.
How to measure it responsibly
Record critical workflow errors, rollback time, cross-tenant denial tests and independently justified operating costs.
Avoid made-up scale benchmarks; measure actual load before re-architecting.
Keep observed outputs, diagnostic scores, inferred causes, and business outcomes in separate fields. A modelled score is not a citation, and correlation is not proof of cause.
What comes next
Keep interfaces and event contracts clear so proven scaling pressures can be addressed without rewriting every business operation.
The durable response is to build pages that are accessible, semantically explicit, useful outside their original layout, and backed by evidence a reader can inspect.
Key takeaways
01Start from tested security and reliability needs.
02Prefer modular simplicity until separation is justified.
03Include runtime and release checks in the architecture.
04Keep AI and search layers subordinate to business truth.
Frequently asked questions
Must an AI SaaS use microservices?
No. A modular app can be appropriate if permissions, queues and operating procedures are properly designed.
Is a shared database safe for tenants?
Only when server-side tenant isolation is enforced and tested. Regulatory needs may justify a different design.
References and further reading
Turn a useful idea into a maintainable product.
Nexis Studio helps organisations move from problem definition to product design, engineering, launch, and long-term support with clear technical and commercial boundaries.
Explore Nexis Studio