Syolo launched their driver portal product supporting 100,000+ drivers

Driver admin was stuck in calls, emails, and office visits

Syolo wanted to build The Driver Portal, a proper self-service layer for driver admin across taxi and private hire fleets.

At the time, most fleets still handled onboarding, document compliance, commission payments, and driver administration through phone calls, emails, and in-person office visits.

The opportunity was obvious because iCabbi already held driver profiles inside the dispatch system, but there was no automated way to keep those records accurate, complete, and auditable for council compliance checks. Fleets were doing the same admin twice: once in the office and again in the dispatch system.

Building the first product version from end to end

I was brought in as the sole contract software engineer to design and build the first version of the product end to end.

That meant shaping the architecture, building the Laravel application, designing the multi-tenant model, integrating payments, handling document storage, and working closely with the founder and iCabbi on what became one of their first large-scale third-party API integrations.

This needed a generalist senior approach. The product was not just a portal screen. It needed authentication, tenant isolation, payments, secure document handling, dispatch synchronisation, and enough operational polish for fleets to trust it with driver compliance.

A multi-tenant Laravel portal connected to iCabbi

I built the platform from scratch using Laravel and PHP, with a responsive frontend using Blade and Alpine.js.

The system used a multi-tenant model with a separate database per fleet. Driver authentication was tied to iCabbi credentials, so fleets could connect the portal to their existing dispatch data rather than asking drivers to maintain yet another identity.

Drivers could upload documents securely, with retention backed by AWS S3. They could also make online payments through Stripe, with optional JudoPay support depending on the fleet.

The synchronisation layer pushed driver details, document numbers, and expiry dates back into iCabbi programmatically. That made the portal part of the operational record rather than a separate website sitting beside it.

Making self-service safe enough for compliance

The main challenge was making self-service feel safe enough for compliance work.

Driver documents affect licensing, availability, and council checks. A simple upload form would not have been enough. The system needed secure storage, clear expiry handling, and reliable synchronisation back into the dispatch platform.

The iCabbi integration was early and large-scale, so the product needed to be careful about assumptions. I had to design the sync layer to handle driver records across multiple fleets while keeping each fleet isolated.

There was also a product adoption challenge. Fleets were used to office-based admin. The portal had to make common jobs easier for both drivers and office staff, otherwise the old habits would win.

100,000+ drivers managed through the portal

The first rollout supported a fleet of more than 2,000 drivers and expanded quickly across the industry.

Fleets moved the majority of document updates and commission payments online, reducing office visits and manual admin. Since inception, the platform has helped manage more than 100,000 drivers.

Adam took The Driver Portal from an idea into a product fleets could rely on. He understood the iCabbi integration, the compliance pressure, and the day-to-day admin we were trying to remove.