Architecture, stack, key decisions and the quality gates DEV3 Lintelo passed before release.
The engineering behind Lintelo: a calendar of cells locked in a fixed order, deadlines applied on read, a bill taken from a booking-time snapshot and extras that need a yes.
The problem it solves
A home services marketplace sells time. Two customers must never be given the same provider hour, a provider must be able to extend a job while a customer is booking the next slot, and every pound has to land in the right place: deposit, extras, balance, fee and provider share. Offers expire, customers cancel and reschedule, and a card may fail days after the job. The numbers must stay right even when several of these happen together.
Architecture and approach
Lintelo is a Laravel 12 application with Filament 4 admin at /admin, a public booking site and a REST API used by two Flutter apps.
Calendar cells
Provider time is stored as cells. Accepting, extending, rescheduling or cancelling a job locks the booking, then the offer, then the provider, then the cells, then the wallets, always in that order through one engine. A duplicate cell counts as an overlap.
Deadlines on read
Every deadline is applied when a record is read, so every test passes with the scheduler off. The scheduled command only sweeps idle records.
Bills from snapshots
A booking keeps a snapshot of its labour at booking time, so plan discounts and catalogue edits cannot change a bill afterwards. A recovered balance is never added to the paid amount twice.
Extras
A provider proposes an extra, the customer has a countdown to approve or decline, and the extension is taken under the provider lock. Maths for calendars, bills, cancellations and refunds is written once in plain classes and tested with vector files that the Dart apps copy.
Apps
The customer and provider apps share one API contract and a shared Flutter package, and start in a demo mode.
Quality gates and results
Lintelo 1.0.0 passed the seven release gates on the final code: 148 Pest tests with 1,376 assertions, 70 pages in a headless browser and 16 race checks on MySQL, the installer test from the zip and a clean secret scan. The customer and provider apps pass analysis and 106 and 141 tests. A review of the money and booking code fixed 15 findings.
Limits are listed on the item page: card charging for balances is simulated, provider documents are images only, and the provider app has no GPS plugin.
Tech stack
| Area |
Technologies |
| Application |
Laravel 12, Filament 4, Blade, REST API |
| Booking |
Provider calendar cells, Job offers, Arrival windows, Cleaning plans |
| Money |
Deposits, Booking-time bill snapshot, Commission rules, Provider settlements |
| Apps |
Flutter customer app, Flutter provider app, Shared dev3 Flutter package, Demo mode |
| Quality |
Pest, Larastan level 6, Headless browser smoke, MySQL race checks |
Inside the build
Open house — A clay-model cutaway house on a plinth with its front door swinging open and warm light spilling out, a van waiting at the kerb.
Rooms — The walls lift away to show the furnished rooms, each one glowing as it is named.