DEV3 Slotwise – Booking & Appointments SaaS Laravel Script with Staff Schedules, Deposits & Reminders

The engineering behind Slotwise, the DEV3 Laravel suite's booking SaaS: Laravel 12 and Filament 4 on the DEV3 core and SaaS packages, four panels, single-database tenancy, metered plans, a slot engine for real staff schedules, deposits with refund rules, reminders, ICS feeds and a widget.

The problem it solves

A booking page looks simple until you compute the times on it. A stylist works 09:00 to 13:00 and 14:00 to 18:00, takes Friday off, needs 15 minutes to clean up after a colour but none after a cut, and shares two colour chairs with three colleagues. The salon is in London, the customer books from Toronto, and the clocks change next Sunday. Two people pick the same 10:30 at the same moment, and one of them chose "anyone available". Then money joins in: a deposit holds the slot while the customer pays, a late cancellation keeps it, an early one refunds it, and a payment that arrives after the hold expired must not leave a ghost booking behind. Reminders have to go out once, and again if the appointment moves. On top of that Slotwise is a SaaS: hundreds of businesses share one database without ever seeing each other's rows, each on a plan with limits, a trial, renewals and invoices, and the platform owner needs MRR and churn. Businesses also want the booking form on their own websites, inside a third-party frame where browsers drop ordinary cookies. And because Slotwise is sold as a script, all of it had to install from a zip on ordinary PHP hosting, with no Node.js, one cron entry and a web installer instead of a terminal.

Architecture and approach

Slotwise is a Laravel 12 application with four Filament 4 panels on one user table: /admin for the platform owner, /app/{business} for each tenant through Filament's tenancy, /staff/{business} for the people who do the work and /account for customers. The marketing site and the booking page are Blade and Livewire with a small vanilla-JS layer, which keeps the public page at 25.5 KB of gzipped JS and CSS.

Two shared DEV3 packages

• The DEV3 core. dev3/laravel-core supplies the installer, typed and encrypted settings, branding, the Blade UI kit, motion and 3D helpers, demo mode, roles and permissions, the audit log, the payment gateways, backups, system health, Sanctum tokens and English / Arabic with RTL. Slotwise registers its demo roles, platform settings (sign-ups, trials, the directory, the SMS driver and website copy), OpenAPI paths and its 3D preset through a product manifest.
• A new SaaS layer. dev3/laravel-saas was written with Slotwise and knows nothing about bookings, so the suite's AI SaaS reuses it. It holds teams, invitations, roles per team, plans, subscriptions, invoices, usage metering, the tenant Billing and Team members pages and the super-admin SaaS resources. The packaging script copies both packages into the zip, so buyers get one self-contained download.

Tenancy, plans and billing

• One database, scoped rows. Every tenant-owned model carries a team_id and a global scope that filters it whenever a tenant is set. Creating a row stamps the current tenant, and saving a row that belongs to another tenant throws. Public pages resolve the business by path, by subdomain or by a custom domain set on the tenant; suspended tenants get a 404. Livewire components on public pages keep the team id in a locked property, because route middleware does not run on Livewire's update requests.
• Limits that count themselves. The plan catalogue declares counted limits (active staff, locations), a metered limit (bookings per calendar month, recorded in a usage table and given back when a booking is cancelled) and seven feature switches. The booking service calls ensure('bookings') before it writes, the staff form stops at the seat limit, and the same catalogue builds the pricing page's comparison table.
• Billing through the core gateway. Choosing a paid plan creates an incomplete subscription, an open invoice and a core payment; the plan starts only when the payment-succeeded event marks the invoice paid, so a declined card changes nothing. A downgrade that the current usage does not fit is refused. A daily saas:renew run ends trials and scheduled cancellations, renews due subscriptions and expires past-due ones after a grace period. Invoices are numbered and rendered as PDF with dompdf, and refunds go back through the gateway.
• Lapsed businesses stop taking bookings. One check in the booking service decides whether a business accepts online bookings: switched off by the owner, a trial that ended or a subscription that expired all block new bookings, while a past-due renewal keeps booking through the grace period. The booking page, the widget and the public API (accepting: false, slots answer 403) all read the same answer and show a friendly notice, /explore hides the business, and existing bookings and their manage links keep working.
• Metrics from history. Subscriptions keep their start and end dates, so MRR, ARR, revenue per account, trials, churn (plan changes excluded), the plan mix and sign-ups are computed for any month, and the demo's twelve-month MRR chart is real data.

The slot engine

• Local days, UTC instants. For each day in the range the engine builds every staff member's working intervals in the business time zone, then converts them to UTC. A split shift is simply two rows for the same weekday, and a 09:00 opening stays at 09:00 across a daylight-saving change. Results are grouped by date in the customer's time zone, which the booking page reads from the browser.
• Busy time with the right buffers. Pending, confirmed, completed and no-show bookings block time, each expanded by its own service's buffers; cancelled bookings free it. Approved time off is added, pending requests are not. A candidate start, stepped at the business's interval, is expanded by the requested service's buffers and must not overlap anything, while the appointment itself must fit inside the working interval.
• Rooms and equipment. When a service needs a resource (a colour chair, a treatment room), a slot survives only if at least one of them is free, and the booking takes the first free one.
• Rules from the business. Minimum notice, the booking window and the start interval come from the business's booking policy, with defaults of 2 hours, 60 days and 15 minutes.
• "Anyone available" and the race. For "anyone" the engine pools every active, bookable person who performs the service, and the booking goes to whoever has the fewest appointments that day. The booking service opens a transaction, locks the candidate staff rows and then the rooms or equipment the service needs with SELECT … FOR UPDATE (always staff first, then rooms, in id order, so concurrent bookings can't deadlock), asks the engine again for that exact start and only then writes, so a second request for the same slot, or for the last free room, fails with a clear message instead of creating a double booking. Rescheduling uses the same path and ignores the booking's own current time.

The booking lifecycle and the money

• Deposits that hold a slot. A service can take a fixed or percentage deposit on plans with the deposits feature. The booking waits as pending, blocking its time, while the customer pays through the core gateway; a scheduled job cancels holds older than the hold window (30 minutes by default). Confirming a paid deposit is idempotent, and a payment that lands after the hold expired is refunded at once.
• Cancellation outcomes in one place. A customer cancelling before the cut-off is refunded through the original payment, later than that the deposit is forfeited, a no-show forfeits it too, and a cancellation by the business always refunds. The customer's cancel dialog states the outcome before they confirm, and the cancellation email repeats it.
• A timeline per booking. Every step (created, deposit paid, confirmed, reminder sent, rescheduled, cancelled, refunded, completed, reviewed) is a booking event linked to the exact email or SMS, which is what the business sees on the booking page.

Reminders, calendars and the widget

• Reminders sent once. Every five minutes the scheduler finds confirmed bookings inside each active rule's offset that have no log entry for that rule and that start time. A rescheduled booking has a new start time, so it is reminded again. SMS rules run only on plans with SMS, through a driver interface with a log driver and a Twilio driver.
• ICS everywhere. Confirmation and reschedule emails attach an invite, the manage link offers a download protected by the booking's token, and each staff member and business has a feed at a secret URL covering the last 30 days and the next 180.
• A widget that survives third-party frames. widget.js is a 4 KB script that adds a floating button or an inline frame and resizes it from postMessage events checked against its own origin. Browsers do not send SameSite=Lax cookies inside a frame on another site, so Livewire would answer 419. For the embed page and its requests over HTTPS, a middleware issues the session cookie as SameSite=None; Secure; Partitioned. Payments break out to the top window, because card forms and 3-D Secure don't run inside third-party frames. When a business turns off guest bookings, the details step signs the customer in or registers them inline, inside the widget too.
• The widget as an enforced plan feature. Hiding the embed code is not enough, so the server checks the plan: without the widget feature the embed page shows a link instead of the form, widget.js asks /api/v1/public/{business}/widget before drawing anything, and the booking page is sent with frame-ancestors 'self' so other sites can't frame it.

Access and security

• Two-factor sign-in from the core. Every panel offers an authenticator app (TOTP) with 8 single-use recovery codes, or email codes. A Require 2FA for staff setting enforces it for the platform team in /admin; for business teams, staff and customers it stays optional. Secrets are encrypted, enabling, disabling and resets are audit-logged, a super-admin can reset a user's 2FA and php artisan dev3:2fa-reset covers a locked-out owner. Demo logins never see the challenge.
• A read-only support role. Support staff sign in to /admin with view permissions only: every mutating SaaS action (plan changes, trials, suspensions, refunds) is hidden, create and edit pages answer 403, and settings, roles and backups are out of reach.
• Business API tokens. Owners and managers on a plan with API access create tokens in the business panel. Each token carries its business id and a bookings:read ability, so the bookings API reads only that business even when the person works for several, and the token stops working when they leave, lose the role or the business drops to a plan without API access.
• Private files in backups. The core's one-click backups include the private storage folder as well as the database and public uploads, and the media library never lists private files.

From sign-up to a live booking page

• An onboarding wizard. A new business picks its name, URL, time zone and industry and starts a trial of the default plan (or the plan chosen on the pricing page). Until onboarding is complete, the panel sends owners to a five-step wizard: business details, opening hours, the first service, the team (limited by the plan's seats) and a go-live step with the booking link and widget code. Each new business also gets a default email and SMS reminder.
• An installer instead of a README. If .env is missing the app creates it and an APP_KEY, then redirects to a 5-step /install wizard: requirements, database (MySQL or SQLite, tested before writing), demo or empty data, the super-admin account and a lock file. php artisan dev3:install does the same over SSH. vendor/ and public/build ship in the zip and the queue defaults to sync, so one cron entry is the only server setup.
• A demo that looks lived in. The seeders build 8 fictional businesses in different countries, currencies and plan states (an Arabic-language clinic in Dubai on a trial, a grooming salon past due, a churned tutoring company) plus 13 recent sign-ups. A bulk generator writes about five months of history and six weeks ahead: 10,204 non-overlapping bookings inside real working hours in every status, 1,015 customers, 49,473 timeline events, 12,514 logged messages, 1,298 payments and 79 subscription invoices. It uses a fixed seed, and it is fast enough to run inside the installer's request.

The 3D and motion approach

• A glass calendar cube in the hero. Each face of a rounded glass cube is a calendar page drawn on a canvas. On load it flips from two days ago to yesterday and lands on today's date, then floats, tilts toward the pointer and re-flips every few seconds while appointment chips orbit it. The pages are redrawn for dark mode and for Arabic.
• Utilisation rings on the dashboard. A large ring shows the team's booked time against its working hours (minus approved time off) for today, the week or the month, with a smaller ring for each person in their calendar colour. They are animated SVG, so the panels need no WebGL.
• Cheap by default. three.js loads lazily as its own 188 KB chunk, the device pixel ratio is capped, the scene pauses off-screen, reduced motion renders the final frame, and an SVG poster shows without WebGL or when 3D is switched off. Reveals, counters and the stacking how-it-works cards come from the core's data-attribute motion.js with Lenis smooth scrolling, not GSAP, which keeps resale licensing simple.

Quality gates and results

Slotwise 1.0.2 passed all seven release gates of the DEV3 Laravel suite, run by one script against the packaged build:

• Static analysis: composer validate, Pint clean, Larastan level 6 with 0 errors (including the SaaS package) and php -l on 273 files.
• Tests: 149 Pest tests with 685 assertions. The required suites cover the slot engine (split shifts, buffers, time off, notice and window, time zones, daylight saving, rooms and "anyone"), the booking lifecycle (double booking, room locks, deposits, refunds and forfeits, hold expiry, reschedule rules, reminders, guest and account bookings), and the SaaS layer (tenant isolation, limits and metering, billing, renewals, lapsed businesses, invoices and MRR), plus business API tokens, the read-only support role, the widget plan feature and two-factor sign-in.
• Front-end budget: 9.9 KB of JS and 15.5 KB of CSS gzipped on the public page (25.5 KB against a 180 KB budget), with the 188 KB three.js chunk loaded only on pages that show the cube.
• Databases: the demo and empty seeders run on both MySQL 8 and SQLite; the demo seed writes 10,204 bookings, 49,473 timeline events, 12,514 messages and 79 invoices.
• Browser checks: 166 pages in headless Chrome with no console errors, plus 8 happy paths: a guest booking without a deposit, a reschedule from the email link, a booking with a simulated deposit, a business sign-up through onboarding to a plan upgrade, a front-desk booking, the widget opening its booking frame on another site, a lapsed business showing its closed state, and the widget script with an ICS feed.
• Installer: the release zip unzipped into a clean folder, installed through the /install wizard on MySQL with demo data, then signed in as the super-admin.
• Secret scan: the 28 MB release zip with 20,032 files, clean, and every text file inside it is scanned again when the listing is published.

The 118 screenshots and the two video tours were captured from the seeded demo across all four panels, light and dark mode, Arabic, tablet and phone, and they double as the listing's demo. They follow a booking step by step, from the service list to the deposit, the business's timeline, the reschedule and the reminder, and a business from sign-up through onboarding to its first paid invoice.

After launch, version 1.0.1 closed the gaps a real platform runs into first: lapsed businesses stop taking bookings, business API tokens, a read-only support role, a server-enforced widget feature, inline sign-in when guest bookings are off and room locks. Version 1.0.2 added two-factor sign-in. The remaining gaps are listed openly: the widget on other websites needs HTTPS; the Stripe, PayPal and Razorpay drivers have not been run against live accounts, and their subscription renewals depend on the gateway's webhook; plan changes are not prorated; there are no group classes or packages; and calendar sync is one-way ICS.

Tech stack

Inside the build

Home page with the 3D glass calendar cube — The cube flips to today’s date and tilts with the cursor while appointment chips orbit around it.

How customers book — Stacking cards walk visitors through service, staff, time and confirmation, each with a live mini preview.