Mono SaaS
A modular Next.js SaaS foundation with separate client and API applications, provider-neutral boundaries, CMS features, billing, and an active multi-tenancy roadmap.
Current portfolio record
Verified against the public repository and current documentation
Purpose and use case
Why this project was built
Built for developers who repeatedly create SaaS products and want a documented starting point that separates reusable platform concerns from product-specific business domains.
Overview
What the project is
Mono SaaS is a reusable application foundation for products that need authentication, administration, content, purchases, billing, configuration, and future team workspaces. It is intentionally shown as an alpha architecture project: several foundations are implemented, while tenant isolation, authorization, integration coverage, and production work remain active roadmap items.
Problem
What it is designed to solve
SaaS projects often rebuild the same authentication, billing, CMS, configuration, storage, and administration foundations. Copying those features between applications also preserves provider coupling and weak tenant boundaries.
Approach
How the project addresses it
The repository separates a Next.js client from a layered API application and defines provider-neutral interfaces for authentication, payments, storage, and configuration. Architecture decisions and workstreams guide the migration from environment-scoped records toward real tenant isolation and RBAC.
Key features
- Separate Next.js client and API applications managed from one repository
- Layered controllers, services, repositories, and provider registries
- Authentication, administrator sessions, CMS, purchases, billing, and reports
- Encrypted database-managed provider configuration
- Documented tenancy, team workspace, RBAC, storage, and webhook roadmap
- Vitest validation and root development orchestration with pnpm
Architecture highlights
- Business services do not access Prisma directly and use repository boundaries
- Provider-neutral contracts isolate Clerk, payment, and storage implementations
- Async request scope is being used as the foundation for authoritative tenant context
- Architecture decision records define tenancy, authentication, boilerplate scope, and object storage
Engineering challenges
- Replacing legacy environment partitioning with real tenant isolation without weakening existing data boundaries
- Removing provider-specific fields from shared schemas while preserving current product behavior
- Keeping the boilerplate focused on reusable platform concerns instead of accumulating unrelated business modules
Implemented outcomes
- Established a clear layered foundation and documented the current system instead of presenting roadmap work as complete
- Encrypted provider secrets and isolated provider-specific authentication and billing behavior
- Created a prioritized master plan with stable workstream IDs, dependencies, and acceptance criteria