What Weblabor Base is

Weblabor Base is a Laravel starter kit. You buy it once, clone it, and build your product on top of it instead of writing the first three months of a SaaS again. Read this first to know what is already there, so you do not build it twice.

What problem it solves

Every product needs the same beginning: accounts, sign-in, an admin panel, roles, plans and payments, notifications, translations, a public site. None of that is what makes your product different, and all of it has to work before the part that does.

Weblabor Base ships that beginning already built, already tested, and already talking to itself: a notification knows about web push, a plan knows about Stripe, a date knows the user's timezone. You add your own models and screens on the same conventions.

What it ships

Everything below is in the repository the day you clone it. Optional parts start turned off and wait for their flag; the guide linked from each item tells you how to turn it on and how to use it.

Accounts and sign-in

• Registration and sign-in by email, phone number, username or any mix of the three, in one step or two. See Configure sign-in and registration.
• Ownership of an email or a phone is verified with a one-time code (OTP). Email codes go through your mailer; phone codes go by SMS through Amazon SNS or by SMS or voice call through Telnyx. The same verification is available inside any form through the <x-email-input> and <x-phone-input> components. See Verify email and phone.
• Password recovery by email, and a forced password change for accounts an administrator created without one.
• An account page at /account where the person edits name, email, phone, username, language and timezone, and a list of the devices signed in, each of which can be disconnected. See Your account area.
• An optional four-digit security PIN, and a trait that makes any Livewire action ask for the PIN or the password before it runs. See The security PIN and Protect sensitive actions.
• Administrators can impersonate any user and block any user.

Admin panel

• A panel at /admin built with Laravel Front: users, roles, announcements, the activity log, the communication log, tracking, categories and Stripe webhook events, each a resource class with no controller and no view to write. See The admin panel and Audit trails and webhook events.
• Roles and permissions on Spatie Permission. A create, retrieve, update and delete permission is generated for every admin resource when you seed, an admin role receives all of them, and super-administrators are named by email in config/app.php. See Roles and permissions and Sudo and super-administrators.
• A DevZone at /admin/dev for super-administrators: edit .env from the browser, run the deploy commands, send yourself a test web push, clear caches and see the commit that is running. See The DevZone.
• A log viewer at /logs. As shipped, that route carries only the web middleware, with no sign-in required, so restrict it before the site is public. See Logs and debugging.

Plans and billing

• Plans, prices, included add-ons and usage limits kept in the database and edited from the admin panel, charged through Stripe with Laravel Cashier. Subscribing and managing a subscription happen on Stripe Checkout and the Stripe Billing Portal from /account/plans and /account/billing. See Turn on plans and billing and Create and price a plan.
• Add-ons sold on top of the plan, as extra items of the same Stripe subscription, from /account/add-ons. See Sell add-ons.
• One-off charges through Stripe Checkout. See Charge once with Stripe Checkout.
• Free trials and Stripe promotion codes on the checkout page. See Free trials and coupons.
• Prices per country with daily exchange rates, usage limits per plan, and a saved payment methods page at /account/payment-methods. See Currencies, intervals and exchange rates and Plan limits and usage.
• A referral program: a code in the URL is kept in a cookie, and the referrer earns a reward on registration and a percentage of each subscription. See Referrals.

Notifications

• One notification class, delivered in the account, by email and by web push, depending on what the person has enabled. A notification centre at /account/notifications. See Send notifications and Email and SMS delivery.
• Announcements written from the admin panel, with an unread counter in the header. See Announcements.
• Web push through the VAPID protocol, and a Progressive Web App with a service worker, an offline page and a manifest ready for PWABuilder. See Web push and the PWA.

Languages, time and place

• Two languages, Spanish and English, chosen by the visitor and then by the account. Missing translations are found with php artisan lang:search and written with php artisan lang:sync through the AI provider you connect. See Languages and translations and Connect an AI provider.
• Every date is stored in UTC and shown in the user's timezone with no code on your side. See Timezones and dates.
• The visitor's country is detected from the IP and completed with Weblabor World, which also powers the country, state and city pickers. See Detect the visitor's country.

Measuring and auditing

• Tracking of sessions and events, reviewed in the admin panel and forwarded to the Facebook Conversions API when you give it a pixel, plus a dashboard of daily metrics. See Dashboard metrics and visitor tracking.
• An activity log of every change to users, roles, permissions, announcements, categories, plans and subscriptions, on Spatie Activity Log. See Activity log.

The public site

• A landing page at /, feature pages at /features, this help centre at /help/en with its guides at /help/en/guides, a changelog at /help/en/changelog, each in every language you publish, and privacy and terms pages. All of them are yours to rewrite. See Make it your own, Brand and interface and Write guides and changelog.

For the developer

• composer dev starts the server, the queue worker, the log tail and Vite in one terminal; queued work and scheduled work are documented in Queues and scheduled work.
• A base model with timezone-aware dates, $guarded instead of $fillable, backed enums, traits for reuse, and routes split into public, /app and /admin groups. See Models, casts and building blocks and Routes, layouts and middleware.
• File storage on the local disk or Amazon S3, with image handling through Intervention Image. See Files, images and storage.
• Laravel Debugbar with an N+1 query detector in local, Larastan for static analysis, PHPUnit and Laravel Dusk for tests, and a pre-push hook that stops a push when a help guide it sends has no translation. See Working on the code and Deploy your project.

What it is built on

The major versions come from composer.json and package.json; the minor version you get is whatever composer install and npm ci resolve on the day.

Development dependencies: Laravel Debugbar 3, Query Detector 2, Larastan 3, PHPUnit 11, Laravel Dusk 8, Playwright 1, Laravel Pail 1, Laravel Sail 1 and the Weblabor coding standards package. The billing package, weblabormx/billing-core, is not downloaded: it lives in packages/billing-core inside the repository and Composer symlinks it from there.

What it is good for

A SaaS with accounts, an admin panel and a monthly or yearly subscription. A product that sells a base plan and optional extras. An internal tool that needs real users, real roles and an audit trail. A product that has to speak two languages and work across timezones from the first day. A web application that people will install on their phone.

What it is not for

A static site or a blog: you would carry an authentication system and a billing package you never use. A product with no accounts at all. An API-only backend, since the interface is Livewire and the routes are pages, not endpoints. A codebase already on another framework, because this is Laravel to the ground and every convention assumes it.