Building a Workplace Lift-Share Platform Around Trust, Maps, and SSO

Context

A workplace lift-share platform was built to make shared commuting feel easier, safer, and more natural for colleagues travelling to the same place. The idea was simple: help people in the same organisation find practical ways to travel together, without turning the product into a public marketplace.

There were no payments, pricing rules, or driver earnings to manage. This was closer to an employee benefit than a transport business, so the product had to feel useful and low-friction while still respecting the trust involved in sharing a journey.

At the centre of the project was a familiar human problem. Someone needs a lift, someone else is already driving, and both people need enough confidence to make the arrangement work. The job was to turn that into a clear product flow that could hold up inside an organisation, with the right access controls and safety rules behind it.

Challenge

Shared commuting depends on trust. Users need confidence that journey details are accurate, pickup locations are handled carefully, and only people from their organisation can participate.

There were several product rules to protect. Every request and journey had to be scoped to the right organisation. Drivers needed to arrange pickups before setting off, rather than adding people while already on the road. Pickup locations also needed privacy controls, so exact home addresses were not shown too early in the process.

The platform also had to work across web and mobile. The same product needed to run as an installable web app and as a Capacitor-based native app, without creating two separate experiences to maintain.

Approach

The build used a spec-driven monorepo, with an OpenAPI contract and feature specs guiding both API and frontend behaviour. The backend was built with NestJS on AWS Lambda, backed by DynamoDB using a single-table design. A geohash index supported location matching without adding a separate spatial database.

Enterprise sign-in was handled through organisation-aware authentication. A user enters their work email, the API checks the verified domain, and the app chooses the right login path. Organisations with OIDC configured see a "Continue with SSO" flow, while other domains can continue through the development-friendly OTP and passkey path.

The OIDC flow uses Authorization Code with PKCE. The app verifies ID tokens against the provider's JWKS, maps configured claims to user attributes, and issues its own session token for application access. That keeps authentication tied to the identity provider while authorisation remains inside the product's own data model.

On the frontend, the product is map-first. Users can set pickup and destination points by tapping the map, with reverse geocoding filling in the address. Address search uses Google Places, while saved locations such as home, work, or headquarters make repeat journeys quicker.

Journey planning works backwards from the required arrival time. If someone needs to arrive at work by 9am, the system calculates the suggested departure time from that constraint. As accepted passengers are added as waypoints, the route is recalculated and the proposed departure shifts earlier where needed.

Matching is handled server-side. Candidate pickup requests are found by organisation, time window, and geospatial proximity, then ranked by the extra detour they would add to the driver's route. Browsing drivers see approximate pickup locations first, with precise details revealed only when the arrangement is accepted.

Engineering foundations

Several safety rules were encoded on the server, not left to the interface alone. The offer-lock rule prevents pickups being arranged while a driver is already on the journey. Organisation boundaries are enforced in API access checks. Admin rules also make sure an organisation cannot accidentally remove its final administrator.

The project also included a framework migration during the build. The API moved from a lightweight HTTP router to NestJS modules, controllers, services, guards, and filters while preserving endpoint behaviour. Route coverage and tests helped keep the migration controlled.

Local development was supported with a pnpm workspace, Docker Compose, LocalStack, and a Makefile. Unit tests covered backend services, while Playwright covered key user flows where browser automation made sense.

Outcome

The result was a clearer foundation for a workplace commute product. The platform supports organisation-scoped access, enterprise SSO, map-based journey planning, and privacy-aware matching without taking on the complexity of payments or public marketplace behaviour.

From a delivery point of view, the main value was reducing ambiguity. The product rules are encoded in the backend, the frontend uses one consistent map interaction across web and mobile, and the authentication model can adapt to each organisation's setup.

Key takeaway

Workplace mobility products need more than a map and a list of journeys. Trust comes from the details: domain-verified access, careful location handling, server-owned journey rules, and a workflow that matches how people actually plan their commute.