Backend foundations (PRO) · Docs

Starter ProBackend

Backend foundations that make the product realLink to section

Starter Free gives you a frontend SaaS surface.

Starter Pro gives you the backend structure, data model, and server-side foundations required to run a real product.

This is where your app stops behaving like a demo and starts behaving like a system:

real persistence
real users
real ownership
real billing state
real server-side rules
real product behavior

One-time payment · Instant access after purchase

Setup guide

Core idea

A SaaS is not only screens. It is data, rules, ownership, access, billing state, and server-side boundaries.

What this solvesLink to section

A lot of SaaS products do not fail because the UI is weak.

They fail because the backend becomes unclear:

data ownership is duplicated
auth and billing are not connected cleanly
access rules leak into components
product logic is scattered across pages
schema decisions become expensive to change
mocked data turns into fragile production logic

Starter Pro gives you a structured foundation so backend work can scale with the product instead of slowing it down.

What is includedLink to section

Database-ready structure

Prisma-oriented schema foundations, migration-ready data modeling, and a clean path from mock data to persistence.

Server-side patterns

Server-side boundaries for product logic, integration logic, access checks, and future API growth.

Auth-aware logic

User ownership, protected data access, session-aware behavior, and backend rules tied to real identity.

Billing-aware boundaries

Product access foundations that can connect billing state, subscription status, and plan-aware behavior.

Architecture layersLink to section

Starter Pro backend foundations are organized around clear responsibilities.

Data layer

Prisma schema foundations
migration-ready structure
typed database access
auth and billing models
future domain models

Application layer

server-side product logic
domain-oriented boundaries
feature-level operations
validation points
reusable backend helpers

Integration layer

auth context
Stripe billing context
webhook processing
email provider boundaries
secure delivery integration

Access layer

protected routes
ownership checks
plan-aware access
admin and user boundaries
server-verifiable permissions

System rule

Keep product rules close to the backend. UI can reflect access, but sensitive logic should be server-verifiable.

Starter Free vs Starter ProLink to section

Capability	Starter Free	Starter Pro
Data source	Mocked	Database-ready
Persistence	Not included	Included foundation
Prisma schema	Not included	Included foundation
User ownership	Conceptual	Auth-aware
Billing access	Conceptual	Billing-aware
Protected data	Mocked	Server-oriented
Server-side patterns	Minimal	Production-oriented
Domain boundaries	Frontend-first	Backend-ready
Best use case	Validate UX	Build launchable product systems

Simple distinction

Starter Free gives you the surface. Starter Pro gives you the system underneath.

ArchitectureLink to section

Data model responsibilitiesLink to section

A real SaaS backend needs models that represent the business layer, not only UI data.

Starter Pro is designed around responsibilities such as:

Area	Purpose
User	Identity, profile, ownership, sessions
Account	OAuth provider connections
Session	Active authenticated sessions
Customer	Billing relationship to Stripe
Product	Sellable product or plan family
Price	Stripe price and commercial plan
Subscription	Access, status, lifecycle, and renewals
Invoice	Payment history and billing state
WebhookEvent	Reliable event processing
Domain models	Your actual product entities

Why this matters

A SaaS backend is not only CRUD. It is the place where identity, revenue, ownership, and product behavior meet.

Feature exampleLink to section

A feature such as Projects behaves very differently depending on the backend layer underneath it.

Demo-style feature

mock state
fake persistence
no ownership rules
no protected access
no billing-aware behavior

Product-ready feature

database model
real create/update/delete flows
user ownership
protected access
auth and billing integration points

This is the difference between a demo feature and a real feature.

Implementation pathLink to section

Validate the existing foundationLink to section

Before adding your domain logic, confirm that auth, billing, database setup, and local seed flows work.

Define your first domain modelLink to section

Add the product entity that matters most to your SaaS.

schema.prisma

model Project {
  id        String   @id @default(cuid())
  name      String
  ownerId   String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

Add ownership rulesLink to section

Connect product data to the authenticated user, customer, or organization model.

server/projects/access.ts

export function canAccessProject(projectOwnerId: string, userId: string) {
  return projectOwnerId === userId;
}

Keep product logic server-sideLink to section

The UI should call the product flow. It should not own sensitive rules.

Connect billing when neededLink to section

If the feature is paid or plan-dependent, add plan-aware checks near the server boundary.

What you avoid building yourselfLink to section

Without Starter Pro, you usually need to design and wire:

database schema foundations
auth-to-user relationships
billing-to-customer relationships
subscription access rules
protected route behavior
webhook state persistence
product ownership checks
delivery access rules
domain separation patterns

This is often time-consuming, easy to duplicate, and expensive to refactor later.

Backend rulesLink to section

Use these rules when extending the backend.

Prefer

clear domain boundaries
server-verifiable ownership checks
centralized plan access logic
database models that reflect product behavior
backend helpers for repeated rules

Avoid

putting access rules only in the UI
duplicating ownership checks across components
mixing billing logic into unrelated features
treating mock data like production data
adding domain models without access rules

Decision guideLink to section

Use Starter Pro backend when:

you need real data
mock states are no longer enough
users need ownership rules
billing status affects product access
backend structure is becoming a blocker
you want less architectural uncertainty before launch

Stay on Starter Free when:

you are still validating UX
product flows are not stable yet
persistence is not required
backend work would slow learning

Upgrade when persistence becomes real

Starter Free helps you validate the product surface. Starter Pro gives you the backend foundation that makes the product launchable.

Production checklistLink to section

Before treating the backend as launch-ready, validate:

database migrations
seed data
user model
session model
billing customer mapping
subscription state
webhook event handling
ownership checks
protected data access
plan-aware access logic
server-side validation
error handling
deployment environment variables

Validation principle

Do not build new product complexity on top of an unvalidated backend. Confirm the foundation first.

Common questionsLink to section

Next stepsLink to section

Secure deliveryLearn how backend ownership and billing state can unlock secure product delivery.Billing systemReview how subscription state and customer ownership connect to backend rules.Authentication systemUnderstand how users, sessions, and identity connect to product data.Production checklistValidate authentication, billing, backend, and delivery before launch.