Use case
Apps & SaaS
Replace your hand-rolled admin UI, REST API, and type definitions with one schema. Ship faster, drift less.
The triple-stack problem
Most SaaS apps grow three parallel systems around the same data:
- An admin UI for support staff and operators.
- A REST or GraphQL API for the product frontend.
- TypeScript types in the codebase that have to stay in sync.
When a field is added, three things must be updated, in three places, by three reviewers. Drift is the natural state.
What Jaina replaces
| Old | New |
|---|---|
| Hand-rolled admin UI | The Jaina GUI, scoped to your project |
| REST endpoints written per resource | Auto-generated endpoints per schema |
TypeScript types living in /types | jaina codegen --lang typescript |
| OpenAPI spec maintained manually | Generated from schema, served at /api/openapi.json |
A typical SaaS schema
{
"Customer": { fields: [name, email, tier, signed_up_at] },
"Subscription": { fields: [customer (ref), plan, period_start, period_end, status] },
"Invoice": { fields: [subscription (ref), amount, paid_at, pdf (file)] }
}
Three schemas, fully editable in the GUI, immediately available via REST, MCP, and typed SDKs.
The auth model
User-scoped API tokens. Row Level Security enforced at the database level. Your admin staff get a GUI; your application gets an API; your support team uses Claude with MCP. Same data, three doors, one set of permissions.
What it isn't
Jaina is not your authentication layer for end users, your billing engine, or your background job queue. It's the structured-data layer underneath them. Most apps will use Supabase / Auth0 / Clerk for end-user auth, Stripe for billing, and Jaina for "the data your team operates on."