A Laravel SaaS starter should give you the boring parts on day one: sign-up, login, roles, an admin, email, an API, logs and backups. It should not decide your billing model or your tenancy model for you, because those are product decisions. Get the boring parts from a base you trust, and spend your first weeks on the one feature customers will pay for.
Disclosure: Lara Dashboard is our open-source, MIT-licensed Laravel CMS and admin. We use it as the example base in this guide, and we say plainly where it stops. Every Lara Dashboard detail below comes from the public repo (develop branch, v1.5.0, Laravel 13, Livewire 4, PHP 8.3+), as of November 2026.
Quick answer: day one is accounts, access, admin and a way to talk to users
Most SaaS starters fail in one of two ways. Some ship too little, so you spend a month rebuilding password resets and role screens. Others ship too much, so you inherit a billing flow, a teams model and a theme you will rip out by month three.
Our rule is simple. On day one you need the parts every SaaS shares and nobody pays for. You can skip, or delay, anything that depends on how you charge and how you separate customers.
Here is the short list we would check before writing the first line of product code:
- Accounts: register, login, email verification, password reset, optional social login.
- Access: roles and permissions, plus a safe way for support to see what a user sees.
- An admin: users, settings, content, and screens for your own models.
- Communication: transactional email templates and a working mail provider.
- An API with token auth and docs, if anything other than your web UI will call you.
- Operations: audit logs, error alerts, monitoring and backups.
- A clear plan for billing and tenancy, even if you build them later.
Accounts are not a feature, so do not build them yourself
Nobody signs up because your login page is clever. They leave because it is broken. Use something that already handles the edge cases.
Lara Dashboard ships the full account flow in
routes/auth.php: login, registration, password reset and email verification. The routes are rate limited. Registration, for example, uses throttle:5,60, and login, registration and password reset all pass through an optional reCAPTCHA middleware. Social login for Google and GitHub is built in through Laravel Socialite, and you switch each provider on in settings with its client ID and secret.One gap to know about: we did not find two-factor authentication in core. If your customers expect 2FA, plan for it early. The Laravel docs cover a two-factor flow in Laravel Fortify. Lara Dashboard uses its own auth controllers, so test any 2FA package against them before you commit. Our post on auth, 2FA and session security covers the wider hardening steps.
Roles and permissions must exist before your first customer
Every SaaS ends up with at least three kinds of people: you, your support staff, and customers. If you start with an
is_admin boolean, you will regret it the day you hire your first support person.Lara Dashboard uses
spatie/laravel-permission, with role and permission screens in the admin. A module can add its own permission group through a filter hook, so your product's permissions sit next to the core ones. Our role-based access control guide walks through it.Support access matters too. Core has a "login as" feature that is gated by the
user.login_as permission, so only roles you choose can impersonate a user. Give that permission to as few people as possible, and tell customers in your terms that support can view their account.An admin panel saves you weeks, if it fits your models
Your team will need to find a user, change a setting, edit a help page, or fix a stuck record. Without an admin, every one of those jobs becomes a Tinker session on production.
Lara Dashboard gives you users, roles, settings, posts and pages, menus, a media library built on Spatie Media Library, translations and the LaraBuilder block editor. For your own product data, you build a module with
nwidart/laravel-modules. The module CRUD generator creates the model, migration and admin screens, and the module keeps its own routes and permissions. We show the full flow in build a Laravel module step by step.That split works well for a SaaS. Your marketing site, docs pages and changelog live in the CMS side. Your product lives in a module. The admin is the same place for both.
Billing and tenancy are product decisions, not starter features
This is where we are most direct. Lara Dashboard core does not include subscription billing or multi-tenancy.
laravel/cashier is listed in composer.json, but core does not make your users billable or ship plan screens. We checked the models, migrations and app code. You decide how you charge, and you wire it up.That is on purpose. Per-seat, usage-based, flat plans, one-off licences and free tiers all need different data. A starter that picks one for you often fights you later.
Billing. For Stripe, start with Laravel Cashier (Stripe). If you want a merchant of record that handles sales tax, look at Cashier (Paddle). If you want a ready-made billing portal, Laravel Spark is the official paid option; check its current price before you plan around it.
Tenancy. Decide early whether customers share one database with a
team_id or tenant_id column, or get a database each. A shared database is simpler and is enough for most B2B tools. Separate databases help with strict data rules, but they make migrations, backups and reporting harder. Our post on building a multi-tenant SaaS compares the options.Even if billing ships in month two, write down the plan on day one. Add the tenant column to your first product tables now. Adding it to twenty tables later is a painful migration.
What a solid base covers, and what you still add
Here is how the day-one list maps to Lara Dashboard core today. "You add" means we did not find it in core, not that it is hard.
| Day-one need | In Lara Dashboard core | You add |
|---|---|---|
| Sign-up, login, reset, verify | Yes, rate limited, optional reCAPTCHA | Your own onboarding steps |
| Social login | Google and GitHub via Socialite | Other providers if needed |
| Two-factor auth | Not found in core | A 2FA package or Fortify flow |
| Roles and permissions | Spatie permission with admin screens | Your product permissions |
| Support impersonation | Login as, gated by user.login_as | A support policy |
| Admin for your models | Modules plus CRUD generator | The models themselves |
| Marketing pages and blog | Posts, pages, LaraBuilder, menus | Your content |
| Transactional email | Templates, mail providers, unsubscribe | Your copy |
| REST API | Sanctum tokens, Scramble docs at /docs/api | Your product endpoints |
| Audit and errors | Action log, daily error digest | Alert routing |
| Monitoring | Pulse and Telescope, permission gated | Uptime checks |
| Backups | Backup service with optional DB dump | Offsite storage and restore drills |
| Billing | Not in core | Cashier, Paddle or Spark |
| Multi-tenancy | Not in core | Your tenancy model |
Email, API and operations are where early SaaS quietly breaks
The features above get attention. These three get forgotten until a customer complains.
Email. Welcome mails, password resets and receipts must arrive. Lara Dashboard has editable email templates, SMTP or PHP mail connections and an unsubscribe flow for marketing mail. Set up SPF, DKIM and DMARC for your sending domain before launch. We cover templates in email templates and campaigns inside Lara Dashboard.
API. If you will have a mobile app, a CLI or integrations, design the API on day one. Core exposes
/api/v1 routes for users, roles, posts and terms behind auth:sanctum, and Scramble generates OpenAPI docs. Add your product endpoints in your module and version them from the start. More in our REST API with Sanctum and Scramble post.Operations. Core keeps an action log of creates, updates and deletes. The scheduler runs a daily error digest command and checks for core and module updates. Laravel Pulse and Telescope are installed and gated by permissions. A backup service can zip the app and modules, with an optional database dump. None of that replaces offsite backups and a tested restore, so read backups, updates and patching a self-hosted Laravel CMS before launch.
Run a real queue worker in production. Lara Dashboard has a queue fallback that runs some jobs synchronously when no worker is running. That keeps a fresh install working, but it is not something to rely on under load.
When not to use Lara Dashboard as your SaaS base
We would rather you pick the right tool than the one we make.
- If you want billing, teams and a customer portal working this week, a dedicated SaaS kit or Laravel Spark gets you there faster.
- If your product is an API only, with no admin users and no marketing pages, a plain Laravel install is lighter.
- If you only need CRUD screens for internal staff, an admin kit like Filament may fit better than a full CMS.
- If you must have 2FA from the first login and cannot add it yourself, choose a starter that ships it.
- If your team does not know Laravel, the module system and hooks will add learning time.
- If you need database-per-tenant isolation on day one, plan that architecture first and check how any base fits it.
Lara Dashboard fits best when your SaaS also needs content: a marketing site, docs, a blog, landing pages, plus a real admin and room to grow through modules. Our comparison of Laravel admin panels covers the other options in more depth.
Day-one self-check for your Laravel SaaS
- A new user can register, verify their email, log in and reset a password.
- Login and registration are rate limited, and you have tested the limits.
- You have at least three roles: owner, support and customer.
- Support impersonation is limited to named roles and written into your terms.
- Your first product tables have a tenant or team column, or you wrote down why not.
- You picked a billing approach, even if it ships later.
- Transactional email passes SPF, DKIM and DMARC checks.
- API routes use token auth and have generated docs.
- Errors reach a person within a day.
- Backups go offsite and you have restored one at least once.
- A queue worker and the scheduler run in production.
- You know whether you need 2FA, and who builds it.
Verdict
A good Laravel SaaS starter removes the work nobody pays for and leaves the product decisions to you. Accounts, roles, an admin, email, an API and basic operations belong on day one. Billing and tenancy need a plan on day one, but the right shape depends on your product.
Lara Dashboard covers most of the shared layer and adds a CMS and a module system on top. It does not ship billing, tenancy or 2FA in core, and we would rather you know that now. If that split suits your next build, try Lara Dashboard, install it locally, and build your first product module before you write a billing line.
FAQ
What should a Laravel SaaS starter include?
At minimum: registration, login, email verification, password reset, roles and permissions, an admin for users and settings, transactional email, and logging. An API with token auth, monitoring and backups are close behind. Billing and tenancy should be planned on day one, even if they ship later.
Does Lara Dashboard include subscription billing?
No, not in core as of November 2026. Laravel Cashier is a composer dependency, but core does not make users billable or ship plan screens. You add billing with Cashier for Stripe, Cashier for Paddle, or Laravel Spark.
Is Lara Dashboard multi-tenant?
Not out of the box. You choose the tenancy model, such as a shared database with a tenant column or a database per tenant, and build it in your module or with a tenancy package.
Does Lara Dashboard support social login?
Yes. Google and GitHub login are built in through Laravel Socialite. You enable each one in settings with its client ID and secret.
Can I build a SaaS API on Lara Dashboard?
Yes. Core uses Laravel Sanctum for token auth and Scramble for OpenAPI docs. You add your own endpoints in a module and protect them with the same middleware and permissions.
Is Lara Dashboard free for commercial SaaS?
The core is MIT licensed, so you can use it in a commercial product. Some modules on the marketplace are paid, and each has its own terms.
