Getting people there, together.

Community transportation is a coordination problem with people at its center. RideOn connects the rider requesting a trip, the driver making it happen, and the organization bringing it all together.

DOMAINMOBILE · COMMUNITY TRANSPORT
TECHNOLOGIESFlutter / FastAPI / PostgreSQL
SOURCEPrivate repository
RideOn platform illustration connecting rider, driver, and operations experiences
01 / THE CONTEXT

The problem
worth solving.

A ride depends on more than a request. Riders, drivers, vehicles, events, assignments, and routes all have to line up, while different organizations need their own operating space.

The product

A multi-tenant transportation platform with dedicated Flutter applications for riders and drivers, a Next.js administration application, and a shared FastAPI backend. An Astro website supports public information and guest ride requests.

02 / THE PRODUCT

What comes together.

01

Rider experience

Registration, ride requests, trip information, and notifications in a dedicated mobile application.

02

Driver coordination

Assignments, navigation, trip status, and location in a separate driver application.

03

Organization operations

Administration across riders, drivers, vehicles, events, assignments, and routes.

03 / UNDER THE SURFACE

The technical foundation.

A high-level map of the published technology stack. Select a layer to explore it.

STACK EXPLORERSELECT A LAYER ↗
↳

FastAPI

The API owns the domain rules behind scheduling, routing, and transportation workflows. Generated Dart and TypeScript clients connect the applications through shared contracts.

ALSO IN THE STACK
AstroDockerBackground workers
04 / THE ENGINEERING LENS

Where the complexity lives.

01

Several clients, one set of rules

The API owns domain rules. Mobile and web clients consume shared contracts, with generated Dart and TypeScript clients keeping their integration aligned.

02

Organization boundaries

Transportation operations are scoped to an organization. Tenant isolation and authorization are part of the platform's data boundaries.

03

Work beyond the request

Scheduling, routing, and background processing extend the system beyond its screens. Separately deployable applications keep client and service responsibilities distinct.

Let’s talk engineering.

Curious about the thinking behind the product? Start a conversation.

NEXT PROJECT / 02

TransactIQ