What is Fayz

Fayz is a SaaS factory. Instead of writing a multi-tenant product from scratch — auth, database, per-customer isolation, CRUD screens, billing — you compose capability plugins on top of a shared engine. A salon, a restaurant and a clinic are the same engine with different plugins turned on. What changes between one product and another is a composition — config + plugins + theme — not a new codebase.

The core idea: a Fayz app doesn't fork the SDK. It sits on a strict ownership boundary, so an improvement in the SDK reaches every app as one migration, not thousands of PRs. You customize anything from a label to an entirely bespoke page without ever ejecting.

The four pieces

Hold on to these four and everything else falls into place:

• SDK — the @fayz-ai/* packages. The headless engine (@fayz-ai/core) defines the plugin contract, the data model and the runtime; the SaaS layer (@fayz-ai/saas) brings multi-tenancy, permissions and the CRUD engine; the UI (@fayz-ai/ui) brings the shell and the components. You install only what you use.
• Plugins — @fayz-ai/plugin-* packages that declare capabilities: scheduling, CRM, finance, menu, courses, inventory. Each plugin brings its own routes, navigation, widgets and database migrations. You turn on the ones you need.
• Supabase — the real backend behind the app: Postgres with multi-tenant RLS, provisioned from the packages you installed. Every app starts in mock mode (zero configuration) and you switch to Supabase when you're ready.
• Deploy — the app is an ordinary web project. Today you publish it as a static site on any host; tomorrow, straight through the managed Fayz platform.

The mental model

A Fayz app describes itself as data. You declare the config, turn on plugins, and that becomes a manifest — the single source the runtime uses to assemble screens, routes and data access:

  app config
       │  (name, theme, locale, backend, which plugins)
       ▼
  plugins enabled ────────────┐
   agenda · crm · financial …  │  each one declares
                               │  routes + navigation + widgets + migrations
       ▼                       ▼
  manifest  ─────────────────────────────────►  runtime
   (the whole app as data)                        │
                                                  ├─► screens  (shell + plugin pages)
                                                  ├─► routes   (generated navigation)
                                                  └─► data     (providers → mock or Supabase)

The same direction holds whether you write the config in JSON (app.manifest.json) or in code (defineSaas): both become the same manifest. Customizing an app is almost always editing that data — not writing new screens.

Fayz and Faya Labs

Fayz is the technology — the SDK, the plugins, the CLI. Faya Labs is the community around it: the people building real products, sharing plugins and helping newcomers. You use Fayz; you join Faya Labs.

Who it's for

For the developer who wants to build a real product — a SaaS that goes to production with paying customers — not a throwaway prototype. If you already know how to put together a web app and you want to stop rewriting the same multi-tenant skeleton on every project, this is your place.

Where to go next