Island Ride: A Nationally Owned Ride-Hailing Platform for Saint Lucia's Taxi Sector
How Converge Solutions built a rider, driver and union administration platform that keeps taxi revenue with National Taxi Union members as international ride-hailing enters the market.
1. Executive Summary
In January 2026, Uber began operating in Saint Lucia. For a taxi sector built on associations, stands and long-standing local relationships, a global operator arriving with a mature mobile product was a structural shift rather than ordinary competition and the commission on every app-based booking would leave the island.
The National Taxi Union commissioned a platform of its own. Converge Solutions was engaged to build it. The brief was not to copy an international ride-hailing app, but to build a platform that works the way the Saint Lucian taxi sector actually works: with the Union and its associations as first-class participants, and with the economics of every trip staying inside the membership.
Island Ride is a three-part platform: a rider application, a driver application and a Union administration console delivered on Android, iOS and the web. It runs on a Spring Boot and MySQL backend, uses WebSocket connections for live trip and dispatch state, Firebase Cloud Messaging for notifications and React Native across both mobile apps, with card payment through PowerTranz and cash settlement recorded in the same ledger. It is live in market.
What Made This Engagement Different
- The Union's federated structure is modelled directly in the platform, with associations defined by location and operating radius rather than flattened into one national driver pool.
- Fleet owners dispatch work to their own drivers and vehicles, reflecting how a large share of local capacity is organised.
- Fixed fare destinations are administered centrally by the Union, preserving the sector's established pricing rather than imposing dynamic metering.
- Every driver holds a self-serve record of trips, earnings and payouts.
- Card acquiring runs through PowerTranz, while cash trips remain fully recorded.
2. Context and Challenge
The NTU is the representative body for taxi operators in Saint Lucia a membership organisation made up of subassociations, each with its own members and stands, alongside independent operators and fleet owners who run several vehicles and employ drivers. That structure is the Union's strength and, for a software project, its central design constraint. A platform that treated every driver as an interchangeable unit in one national pool would have dissolved the associations that give the sector its shape.
Uber's entry created pressure that was not about price. A visitor could open an app they already had installed, see a fare before travelling and pay by card. The Union's assessment was that the shift to app-based booking was permanent, and that the only durable response was to own the channel. In June 2026 the Union convened members to introduce the platform; the session was positioned as a consultation, not a launch, and two questions dominated how the system would be governed, and how and when a driver would be paid. Both went directly into the product.
| Challenge | Design Response |
|---|---|
| Competing with a mature global product | Parity on the fundamentals — in-app booking, live tracking, digital payment, receipts and ratings delivered natively on Android and iOS. |
| A federated membership structure | Associations are first-class entities with defined location and operating radius. Drivers register against their association; the Union administers across all of them. |
| Fleet owners, not just individual drivers | A fleet role lets an owner assign vehicles to drivers and allocate jobs across the fleet, with fleet composition visible to the Union. |
| Driver trust in payment | A per-driver earnings ledger with daily, weekly and monthly views, payout history and settled status, covering both card and cash trips. |
| Card acquiring in the Eastern Caribbean | PowerTranz integration with tokenised card-on-file, so cardholder data never lands in platform systems. |
| Union oversight and administration | A dedicated web console for member verification, association management, fleet oversight, fare control and live ride monitoring. |
| Seasonal demand and mixed devices | Cloud-hosted horizontally scalable services, and React Native for one consistent codebase across the driver and rider device estate. |
“The entire project scope is a three-part app.”
3. Platform Overview
Island Ride was scoped as three connected products sharing one backend, one data model and one identity system. A change to a driver's association status, a vehicle's compliance record or a trip's payment state is immediately consistent everywhere the Union administrator, the fleet owner and the rider see the same record.
| Component | User | Purpose |
|---|---|---|
|
Rider Application
Android / iOS |
Residents and visitors | Book a taxi, track the assigned vehicle, pay by card or cash, rate the trip and retain a history. |
|
Driver Application
Android / iOS |
NTU member drivers and fleet owners | Go online, receive and run jobs, dispatch to fleet drivers, and review trips, earnings and payouts. |
|
Administration Console
Web |
NTU and association administrators | Verify members, manage associations and fleets, set fare destinations and monitor rides. |
4. Driver Application
The driver application is the platform's centre of gravity. It carries availability, dispatch, navigation context, earnings and compliance in one place, and it was built to be legible to a driver who has never used a dispatch app before.
Driver home availability, live earnings, rating and recent trips
Earnings daily, weekly and monthly breakdown with payout history
Account profile, verification documents and support
Driver Home
Availability, live earnings, rating and recent trips.
Earnings
Daily, weekly and monthly breakdown with payout history.
Account
Account profile, verification documents and support.
Availability
Online and offline control so a driver decides when they are visible to dispatch.
- Online and offline control, so a driver decides when they are visible to dispatch.
- At-a-glance earnings, completed trip count and rating on the home screen, with recent trips and their status.
- Earnings broken down daily, weekly and monthly: total fare, tips and adjustments with payout history and settled status.
- Documents held against the driver profile: licence, vehicle registration and insurance, submitted for Union verification.
- Trip history covering every completed journey, and rider ratings captured at completion.
5. Trip Completion and Settlement
Completion is the moment the platform earns or loses driver trust, so it was designed as a settlement step rather than a dismissal screen. The driver sees the fare, the distance and the total earned, together with how the trip was paid, before moving on.
Card payments are confirmed against the gateway at completion. Where the payment service cannot be reached a real condition on an island with uneven mobile coverage the platform says so plainly and prompts the driver to check with the rider before they leave, rather than reporting a false success. The confirmation can be retried, and the trip remains open in the ledger until its payment state is resolved. Cash trips are recorded against the same ledger with the method shown explicitly, so a driver's earnings history is complete regardless of how a rider chose to pay.
Settlement — unconfirmed card payment surfaced honestly, with retry
Completion — two-way rating captured at the end of the trip
Completion — fare, distance, earnings and payment method
6. Union Administration Console
The administration console is what makes this a union platform rather than a marketplace. It gives NTU a live operating picture and the controls to govern membership, and it is organised around the way the Union is actually structured associations, fleets, drivers, riders, fares and rides.
Dashboard — users, drivers, active drivers and fleet network at a glance, with pending approvals
The dashboard reports registered users and drivers, how many are currently active, and the shape of the fleet network owners, associations, drivers and vehicles alongside driver status distribution and the approvals queue. Pending approvals are surfaced as work to be done rather than buried in a report.
Associations — partner organisations and unions, each with location and operating radius
Associations are managed as real entities with a geographic centre and an operating radius, and can be viewed on a map. This is the mechanism that keeps the Union's federated structure intact inside the software: a driver belongs to an association, and an association carries its own territory.
Associations — partner organisations and unions, each with location and operating radius
Driver management covers the full membership lifecycle. Administrators see total registered, active, blocked and suspended counts, search by name, vehicle or licence, and review each driver's vehicle class, fleet role, performance rating and submitted documents driving licence, registration and tourism permits before approving them onto the platform
- Fleet management for owner-operated groups, with vehicles and drivers mapped to the owner
- Rider management alongside driver management, so disputes can be handled from both sides.
- Fare destinations administered centrally, preserving the sector's fixed-fare pricing between known points.
- Ride monitoring for live and completed journeys.
- Role-based access, with senior operator and administrator roles separated.
7. Technology Architecture
The architecture was chosen for operational durability rather than novelty. A union-owned platform has to be maintainable over years by a small team, run predictably on modest infrastructure, and keep financial records that reconcile exactly.
| Layer | Technology | Role |
|---|---|---|
| Mobile clients | React Native | Rider and driver apps for Android and iOS from a single codebase, with native modules for location and background behaviour. |
| Web client | React-based web application | The Union and association administration console. |
| Application services | Spring Boot (Java) | REST APIs, dispatch and matching, fare rules, association and fleet hierarchy, payment orchestration. |
| Real-time layer | WebSocket | Driver location streaming, job offers and live trip state. |
| Notifications | Firebase Cloud Messaging | Booking, dispatch and trip events delivered when apps are backgrounded or closed. |
| Data | MySQL | Relational store of record for members, associations, vehicles, trips, fares and ledgers. |
| Payments | PowerTranz gateway | Card authorisation, capture, refunds and tokenised card-on-file. |
| Infrastructure | Cloud-hosted | Containerised services, managed database, object storage, load balancing, elastic scaling. |
7.1 Backend and Data
The backend is a set of Spring Boot services exposing versioned REST APIs to all three clients. Java was selected for the maturity of its transactional tooling and for the availability of engineers able to maintain the platform locally over the long term.
MySQL is the store of record, and a relational model was correct here because the domain is inherently relational and the financial records must be exact.
Foreign keys enforce those relationships at the database. Financial writes run inside transactions so that trip completion, payment capture and ledger entries either all commit or none do.
7.2 Real-Time Layer and Notifications
Ride-hailing is a real-time problem. Persistent WebSocket connections carry driver location updates, job offers and expiry, trip state transitions and fleet dispatch events.
Connections are authenticated on establishment and re-authenticated on reconnection. Clients reconnect with backoff and resynchronise trip state from the API on recovery.
Firebase Cloud Messaging handles job offers, booking and arrival alerts, payment outcomes and Union broadcasts targeted by association.
8. Cloud Infrastructure
Demand for taxis in Saint Lucia is not evenly distributed. It concentrates around cruise arrivals, flight schedules, tourist season and events, and collapses between them. Island Ride is therefore cloud-hosted throughout, with capacity that follows demand.
| Capability | Implementation | Why It Matters to NTU |
|---|---|---|
| Elastic Compute | Containerised Spring Boot services behind a managed load balancer, scaled horizontally on CPU and connection load. | Arrival peaks are absorbed automatically; quiet periods cost less. |
| Stateless Services | Session and connection state held outside application instances. | Instances can be added, replaced or patched without disrupting active trips. |
| Managed Database | Managed MySQL with automated backup, point-in-time recovery and a standby in a second availability zone. | Financial and trip records survive infrastructure failure. |
| Object Storage | Driver and vehicle documents stored as objects, served over a content delivery layer. | Verification records are retained durably and cheaply; the database stays fast. |
| Real-Time Capacity | WebSocket termination sized separately from request handling, with sticky routing. | Live tracking stays stable as concurrent driver connections rise. |
| Monitoring | Centralised logging, performance monitoring, uptime checks and threshold alerting. | Problems are detected by the platform team. |
| Security and Recovery | Private networking, restricted ingress, encryption in transit and at rest, managed secrets and tested restores. | Member data stays behind defined boundaries and remains recoverable. |
The commercial consequence is that the Union carries no hardware, no refresh cycle and no fixed capacity commitment: operating cost tracks trips completed.
The platform is not confined to one island; additional associations or territories extend the same deployment model.
9. Payment Integration — PowerTranz
Payment was the most scrutinised part of the platform. Visitors expect to pay by card without discussion. Drivers needed to know that a cashless booking still results in reliable, traceable payment. And the Union needed a record it could reconcile.
9.1 Why PowerTranz
- Built for Caribbean acquiring, with regional bank relationships and currency handling appropriate to the Eastern Caribbean.
- Card-on-file tokenisation, so a rider can save a card without the platform ever storing card data.
- 3-D Secure cardholder authentication for cross-border transactions.
- Authorisation, capture, void and refund operations across the trip lifecycle.
- Transaction identifiers that reconcile against platform trip records line by line.
9.2 Transaction Flow
The rider selects card payment at booking. Card details are captured through the gateway's hosted, PCI-compliant path.
PowerTranz returns a token representing the card. The platform stores only the token, last four digits and brand for display.
An authorisation is placed against the fare at booking, confirming funds before a driver is dispatched.
The trip runs, with state tracked over WebSocket and written to MySQL at each transition.
On completion the transaction is captured for the settled amount; voids and partial captures handle cancellations and adjustments.
Where the gateway cannot be reached, the driver is told the payment is unconfirmed and prompted to resolve it with the rider.
Payment result, gateway reference and ledger entries are written in a single database transaction. Cash trips post to the same ledger.
The rider receives a receipt, the driver's earnings and payout history update, and the Union console reflects the transaction.
Payment Integrity by Design
- No card number reaches platform infrastructure — tokenisation confines cardholder data to the gateway's PCI scope.
- Payment operations are idempotent and keyed, so a retried request cannot double-charge a rider.
- Every trip carries the gateway transaction reference, making platform records and acquirer statements reconcilable line by line.
- The driver ledger is derived from captured transactions and recorded cash, not from estimates.
- Unconfirmed payments are surfaced to the driver rather than resolved optimistically in the background.
10. Security and Governance
| Area | Approach |
|---|---|
| Access Control | Token-based authentication across all three clients, with role-based authorisation spanning rider, driver, fleet owner, association administrator and Union administrator. |
| Payment Data | No cardholder data stored, processed or transmitted by platform systems; tokenisation confines card data to the gateway. |
| Data Protection | TLS on API, web and real-time traffic; encryption at rest for the database and object storage; managed key and secret handling. |
| Member Documents | Licence, registration, insurance and permit records held in access-controlled storage, retrievable only by authorised administrators. |
| Location Data | Collected for dispatch, tracking and trip records, and retained against the trip rather than as an open-ended movement history. |
| Auditability | Immutable audit trails on member status changes, fare configuration, trip state and payment events. |
11. Outcomes
Island Ride is live in market on Android, iOS and the web. Its significance to the Union is less about any single feature than about what the membership now controls.
- A booking channel the sector owns. Members compete for app-based bookings on their own platform, and the commercial value of a digital trip stays within the membership.
- The Union's structure preserved in software. Associations exist as real entities with their own territory, and administration follows the lines of authority the Union already uses.
- Transparency for drivers. Every member has a self-serve record of trips, earnings, tips, adjustments and payouts — the question raised most sharply in consultation, answered by the product rather than by assurance.
- Fleet owners operating digitally. Allocation that had been managed by phone now runs inside a system with records the Union can see.
- Parity for riders. In-app booking, live tracking, card or cash payment, receipts and ratings, delivered by local drivers who can be identified before boarding.
- Administrative visibility the Union never had. Verification, fleet composition, fare destinations and ride activity now sit in one console.
- A foundation that extends. Corporate and hotel accounts, scheduled journeys, tourism operator integrations, additional associations and deeper analytics extend the existing platform rather than requiring a new one.
12. About Converge Solutions
Converge Solutions designs and builds production software for organisations that need systems matched to how they actually operate.
This engagement spanned discovery with a membership organisation, mobile and web product development, real-time systems engineering, regional payment integration and cloud infrastructure delivery.
For more information on Island Ride or comparable engagements, contact Converge Solutions.
