Build a Multi-Tenant SaaS Backend

Building a SaaS backend means solving the same structural problems every time: multi-tenancy, authentication, role-based access, APIs, database migrations, and deployment. Connect Apso to Claude or Codex, describe the product and its access rules, then review the schema your agent creates before Apso generates the service.

The Multi-Tenancy Problem

Every SaaS app needs tenant isolation. Users in one workspace should never see data from another. Most teams implement this manually by adding WHERE workspaceId = ? to every query, or by configuring PostgreSQL Row-Level Security policies.

Apso handles this at the application layer. Add scopeBy: "workspaceId" to an entity in your .apsorc schema and the generated code automatically filters all queries by the authenticated user's workspace.

{
  "name": "Project",
  "scopeBy": "workspaceId",
  "fields": [
    { "name": "name", "type": "text", "length": 255 },
    { "name": "status", "type": "text", "length": 50 }
  ]
}

The generated guard:

• Filters all list queries by workspaceId
• Injects workspaceId on create operations
• Verifies ownership on single-resource access (GET/PUT/DELETE by ID)

Authentication That Fits Your Stack

SaaS products often start with one auth provider and migrate to another as requirements change. Apso supports BetterAuth, Auth0, Clerk, Cognito, and API keys through the BYOA (Bring Your Own Auth) pattern.

The generated auth guard produces a normalized AuthContext interface. Your business logic never touches provider-specific code. When you need to switch providers, change one line in your schema and regenerate.

The Extensions Pattern

SaaS backends always need custom business logic beyond CRUD. Apso separates generated code from your customizations:

• src/autogen/ contains generated entities, controllers, and services (regenerated on schema changes)
• src/extensions/ contains your custom business logic (never overwritten)

Add custom endpoints, validation rules, webhook handlers, or third-party integrations in extensions. Regenerate your schema as often as you need without losing your work.

Deploy to Production

Apso deploys your SaaS backend to AWS using Lambda for compute, RDS for the database, and API Gateway for routing. The infrastructure is provisioned via Step Functions and monitored through the Apso dashboard.

Each service runs independently with its own scaling, domain, and database. Scale your API service separately from your billing service or notification service.

Build It With Your Agent

1. Connect the Apso MCP server and skills to Claude or Codex.
2. Describe the users, workspaces, roles, resources, and tenant boundaries in your product.
3. Ask your agent to start from the Multi-Tenant Workspaces model and adapt it to your requirements.
4. Review the resulting .apsorc schema, especially relationships, scopeBy rules, and authentication context.
5. Let the agent generate the service through Apso, then run the normal framework tests before adding product-specific logic.

Use the Apso quickstart for connection and generation steps.