What Weblabor Base is

Weblabor Base is the starting point for an online product. You buy it once and build your product on top of it, instead of making the first three months of a subscription product again. Read this first to know what is already there, so nobody builds it twice.

What problem it solves

Every product needs the same beginning: accounts, sign-in, an admin panel, roles, plans and payments, notifications, two languages, 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 comes with that beginning already built, already tested, and already working together: a notification can reach the browser, a plan knows how to charge, a date is shown in each person's own time zone. Your own screens are added on top, the same way.

What it comes with

Everything below is there from the first day. Optional parts start switched off and are turned on when your product needs them; the guide linked from each item explains 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.
• An email or a phone is confirmed with a one-time code, sent by email, by text message or by voice call. See Verify email and phone.
• Password recovery by email, and a forced password change for accounts an administrator created without one.
• An account page where each person edits their name, email, phone, username, language and time zone, and sees the devices they are signed in on, each of which can be disconnected. See Your account area.
• An optional four-digit security PIN, asked for before sensitive actions. See The security PIN and Protect sensitive actions.
• Administrators can act as another user, to see what they see, and can block users. Only one of the product's owners can act as another owner, and nobody who holds the Admin role can be blocked.

Admin panel

• A panel to manage users, roles, announcements, the activity history, the record of emails and text messages sent, visitor tracking and payment events. See The admin panel and Audit trails and webhook events.
• Roles and permissions: what each role can do is ticked on one screen, the Admin role has full access, and the product's owners get a few extras on top. See Roles and permissions and Sudo and super-administrators.
• A tools area for the product's owners, to change settings, publish updates and check what is running. See The DevZone.
• A screen to read the application's error log. See Logs and debugging.

Plans and billing

• Plans, prices, included extras and usage limits, edited from the admin panel and charged by card through Stripe. People subscribe and manage their subscription from their account. See Turn on plans and billing and Create and price a plan.
• Add-ons sold on top of the plan, on the same subscription. See Sell add-ons.
• One-off charges for anything that is neither a plan nor an add-on. See Charge once with Stripe Checkout.
• Free trials and promotion codes at checkout. See Free trials and coupons.
• Prices per country with daily exchange rates, usage limits per plan, and a page to save payment methods. See Currencies, intervals and exchange rates and Plan limits and usage.
• A referral program: each user gets a link, and earns a reward when someone registers through it and a share of what that person pays. See Referrals.

Notifications

• Notices delivered in the account, by email and as browser notifications, depending on what each person has turned on, with a notification centre in the account. See Send notifications and Email and SMS delivery.
• Announcements written from the admin panel, with an unread counter at the top of the screen. See Announcements.
• Browser notifications, and a site people can install on their phone like an app. See Web push and the PWA.

Files and support

• A media library where each account keeps its files and images in folders, and a page that shows how much room the account takes up, with a disk space limit per plan when plans are on. See Files, images and storage and The space pages.
• Support tickets: people write to your team from their account, and the team answers from a shared inbox with response deadlines. Explained in the guide «Support tickets», available when the tickets module is on.
• A live support chat between a person and your team, which needs real time running. Explained in the guide «Live support chat», available when the live chat is on, and in Real time with Reverb.
• A support assistant for your team: a conversation with Claude that reads the product's code and its data without changing anything. Explained in the guide «Support assistant», available when the assistant is on.

Languages, time and place

• Two languages, Spanish and English, chosen by the visitor and then by the account, with new interface text translated by a single command. See Languages and translations.
• Every date is shown in each person's own time zone. See Timezones and dates.
• The visitor's country is detected on arrival, and the country, state and city pickers come filled in. See Detect the visitor's country.

Measuring and auditing

• Tracking of visits and events, reviewed in the admin panel and sent to Facebook advertising when you connect it, plus a dashboard of daily figures. See Dashboard metrics and visitor tracking.
• A history of every change to users, roles, permissions, announcements, categories, plans and subscriptions. See Activity log.

The public site

• A home page, feature pages, this help centre with its guides and its list of changes, 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.

What it is good for

A product 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 a history of changes. A product that has to speak two languages and work across time zones from the first day. A web application that people will install on their phone.

What it is not for

A simple website or a blog: you would carry sign-in and billing you never use. A product with no accounts at all. A product that only offers data to other systems and has no screens of its own. A product already built on another technology, because everything here assumes the one it is built on, listed below.

For developers

Weblabor Base is a Laravel starter kit: you clone it and build your product on its conventions.

• What sits where. The admin panel is at /admin, built with Laravel Front, each screen a resource class with no controller and no view to write. Roles and permissions run on Spatie Permission: when you seed, every admin resource gets a create, retrieve, update and delete permission for each of those actions the resource offers, the role named by config('app.admin_role') (admin by default) receives all of them, and super-administrators are named by email in config/app.php. The DevZone is at /admin/dev: edit .env from the browser, run the deploy commands, send a test web push, clear the log cache and see the running commit. The log viewer is at /logs and, as shipped, carries only the web middleware with no sign-in required, so restrict it before the site is public.
• Accounts. Email codes go through your mailer; phone codes go by SMS through Amazon SNS or by SMS or voice through Telnyx. The same verification is available in any form through the <x-email-input> and <x-phone-input> components. A trait makes any Livewire action ask for the PIN or the password before it runs. The account page is /account.
• Billing. Plans and limits live in the database and are charged with Laravel Cashier on Stripe Checkout and the Stripe Billing Portal, from /account/plans, /account/billing, /account/add-ons and /account/payment-methods. Add-ons are extra items of the same Stripe subscription. The referral code travels in the URL and is kept in a cookie.
• Notifications. One notification class, three channels; the notification centre is /account/notifications. Web push uses VAPID, and the PWA ships a service worker, an offline page and a manifest ready for PWABuilder.
• Languages, time and place. Missing translations are found with php artisan lang:search and written with php artisan lang:sync through the AI provider you connect (Connect an AI provider). Dates are stored in UTC. The country comes from the IP and is completed with Weblabor World, which also powers the pickers. The activity history runs on Spatie Activity Log, and tracking forwards to the Facebook Conversions API when you give it a pixel.
• The public site. The landing is /, the feature pages /features, the help centre /en/help with its guides at /en/help/guides and the changelog at /en/help/changelog.
• Working on it. composer dev starts the server, the queue worker, the log tail and Vite in one terminal; queued and scheduled work are 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 images through Intervention Image: see Files, images and storage. Laravel Debugbar with an N+1 query detector in local, Larastan, PHPUnit and Laravel Dusk, 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.
• Not for an API-only backend, since the interface is Livewire and the routes are pages, not endpoints, nor a codebase on another framework: this is Laravel to the ground.

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.