Why Tiger?

You want to build a SaaS. What you do not want to build — again — is login, signup, password reset, multi-tenant orgs, roles, permissions, an admin shell, an API layer, theming, and the seventeen other things standing between you and your actual product.

That's the plumbing. Tiger is the plumbing. You build product.

Phenomenal cosmic powers, itty-bitty living space 🧞

Tiger is a 1-click, multi-tenant SaaS foundation — think "a better-architected WordPress, but for SaaS." Before you write a single line of your own code, you already have:

  • 🏢 Real multi-tenancy — orgs, users, and memberships, where a role lives on the membership. The same person can be an admin in one workspace and a viewer in another. Cross-tenant access isn't blocked by a code check you might forget — it's blocked by the absence of a membership row.
  • 🔐 Auth done right — email-or-username login, hashed + peppered passwords, 2FA-ready, DB-backed sessions, server-authoritative auto-logout.
  • 🛡️ ACL, deny-by-default — every request is authorized against data, never a hardcoded if ($role === 'admin').
  • ⚡ A webservices layer where shipping an endpoint means writing a method. No REST endpoint zoo.
  • 🎨 A zero-build UI — vendored Bootstrap, runtime CSS-variable theming, swappable skins. No npm. No webpack. No node_modules event horizon.
  • 🧩 Drop-in modules — features that plug in by convention and never touch the core.
  • 📝 A CMS, an admin shell, i18n, media storage, and live config — the boring-but-essential stuff, already boring and essential.

Built for the vibe

Here's the part that matters right now: Tiger is designed to be read and written by an AI.

  • The docs live in the code. Conventions are consistent and enforced, so an agent (or a new human) can read one module and know exactly how to build the next.
  • Extending is boringly predictable: add a method, add a module, layer a config file. There's a right way, and it's the obvious way.
  • Nothing you build gets clobbered on update — so you can move fast without breaking your own stuff.

Vibe-code an MVP over a weekend, and Tiger holds the parts that have to be right — the tenancy boundary, the auth, the permission checks — so your 3 a.m. "ship it" energy lands on features, not foot-guns.

The one rule that makes it all work

Extend, don't edit.

The framework lives in vendor/ (owned by Tiger, replaced by composer update). Everything else is yours. You customize by adding — modules, config overrides, subclasses, skins — never by hacking a core file. So composer update keeps you current without ever eating your work.

That's the whole trick. It's why Tiger updates like a dependency instead of rotting like a fork.