The problem
Most commuting journeys are made alone, in a car with four empty seats, to a workplace with a car park that is too small. The cost sits with the employee, the parking pressure sits with the employer, and the emissions sit with everyone.
Consumer carpooling apps exist, but they are built around long-distance intercity travel. A five-mile commute to an industrial estate has a different economic shape: low value per journey, high frequency, and a matching problem that only works if enough people from the same destination are on the platform at the same time.
Who the customer is
Two customers, and they are not the same person. The user is a commuter who wants a cheaper, easier way to get to work. The buyer is an employer, campus or business park with a parking, travel-plan or sustainability obligation.
The employer relationship is what makes the matching problem solvable: a single workplace gives you a dense pool of people travelling to the same postcode at roughly the same time.
What users currently do instead
- Driving alone and absorbing the fuel and parking cost.
- Informal arrangements over WhatsApp groups and staff notice boards, which work until someone changes shift.
- Public transport where it happens to fit, which for out-of-town employment sites it often does not.
The core product journey
- A driver publishes a regular journey: origin area, destination workplace, departure window, seats available.
- A passenger searching the same workplace sees matches ranked by detour distance and timing fit rather than by raw proximity.
- Both sides see a verified profile and a clear shared cost before anyone commits.
- The journey is confirmed, repeated on a schedule, and recorded so the employer can see participation without seeing personal travel detail they should not have.
The hardest product decision
Whether to launch consumer-first or employer-first. Consumer-first is faster to ship and impossible to make liquid: a matching marketplace with thin, scattered supply produces no matches, and a user who sees no matches does not come back.
The decision was to make the employer the unit of launch. It slows acquisition and it makes the sales cycle longer, but it is the only version where the first user has a realistic chance of finding a match on day one.
What I deliberately did not build
- In-app payments. Cost sharing is displayed and agreed, not processed, until there is evidence that payment friction is what stops journeys happening.
- A native mobile app. Web-first keeps the build narrow and the iteration fast.
- Ratings, gamification and social features. They are easy to add and they distract from the only question that matters at this stage: do matches actually get made and repeated.
- Long-distance and one-off leisure travel, which is a different product with a different competitor set.
Business model
Workplace subscription: the employer pays for access, participation reporting and travel-plan evidence. Commuters use it free, because charging the person you need to acquire in volume is the fastest way to kill liquidity.
That model is a hypothesis with a clear test attached, not a proven revenue line.
Technology and AI approach
Web-first application with a hosted database, authentication and role separation between commuter, employer administrator and platform administrator.
Matching is deterministic rather than model-driven: route overlap, timing windows and detour tolerance. AI is used where it earns its place, mostly around cleaning and interpreting the messy free-text of real addresses and shift patterns.
Reporting is aggregate by design so an employer sees participation, not individual movements.
Screenshots
The product surfaces that carry the journey.
Journey creation
Co-Ride journey creation screen where a driver sets route, time and available seats
Journey matching
Co-Ride workplace carpool journey matching screen showing suggested passengers on the same route
Driver and passenger profile
Co-Ride driver and passenger profile screen showing verification and journey history
Shared journey cost
Co-Ride shared journey cost breakdown between driver and passengers
Employer dashboard
Co-Ride employer dashboard showing participating staff and active workplace journeys
Sustainability reporting
Co-Ride sustainability reporting view showing avoided single-occupancy journeys
What this demonstrates
- Designing a two-sided marketplace where the buyer and the user are different people.
- Choosing a launch unit that makes liquidity possible instead of one that makes acquisition easy.
- Building trust and safety into a product where strangers share a car.
- Turning a sustainability obligation into a commercial product rather than a corporate poster.
What has been validated
- The problem is real and well documented: parking pressure and single-occupancy commuting are recognised issues for large employment sites.
- The product journey holds together end to end in build and in walkthroughs with prospective users.
What still needs validation
- Whether an employer will pay, and how much, for participation and reporting.
- Whether match density at a single workplace is high enough to produce repeat journeys.
- Whether commuters keep using it after the novelty of the first few journeys.
What I would test next
- One paid pilot at a single site with a car park problem, priced properly rather than given away.
- A match-rate measurement: of the passengers who search, what proportion get a usable match within their timing window.
- A four-week repeat-journey measurement, which is the real retention signal for a commuting product.