Appearance
Introduction
Laraspring is a commercial SaaS starter kit for Laravel. It gives you the parts every SaaS rebuilds from scratch, authentication, organizations, billing, transactional mail, file storage, permissions and internationalization, as packages you install rather than code you copy.
Pre-alpha
The monorepo skeleton is in place, the package pattern is proven end to end, and seven domain packages ship alongside laraspring/core. Everything documented here can still change.
How it is organized
packages/*holds the core as framework-agnostic Composer packages under theLaraspring\namespace. They never depend on an application.apps/*holds the editions and supporting apps.apps/saasis the React edition andapps/vuethe Vue one, both complete;apps/docsis this site. You buy one edition and it arrives as a repository of its own. See Editions.
Agent-native
The repository is written to be read by coding agents as much as by people. AGENTS.md at the root states the conventions an agent needs before it edits anything, and .claude/skills/ holds step-by-step procedures for the jobs you will repeat, each written against the repository's real files and commands. Behind both sits the thing that makes them safe: 859 tests and six gates every change has to survive, whoever wrote it. See Working with coding agents.
What ships today
laraspring/auth owns registration, login, sessions, password reset, email verification, magic links, social sign-in and two-factor authentication. laraspring/organizations owns membership, roles, invitations and the active tenant. laraspring/billing owns the plan catalogue, subscriptions and the payment provider adapters, with Stripe first. laraspring/mail owns the branded template every transactional email is drawn inside, and the preview browser for it. laraspring/storage owns direct-to-bucket uploads. laraspring/i18n owns the locale, with every string in the kit translated into English and Spanish. laraspring/admin owns the administration panel, suspensions and impersonation.
Both editions are left as a thin presentation layer over all seven: no behaviour lives in an edition that a package could own, which is why there can be two of them and why the pages on this site apply to either.
Paths on this site are relative to your edition, so config/brand.php is apps/saas/config/brand.php or apps/vue/config/brand.php depending on which one you bought. The frontend examples are React, because that is the reference edition; Editions has the mapping and the full list of what differs, which is short.