What If Ride-Hailing Was Built for Communities, Not Shareholders?

The Problem

What if a ride-hailing service was structured as a non-profit?

Ride-hailing has become essential urban infrastructure, yet the dominant platforms — Uber, Bolt, Lyft — are built around extracting maximum value from every trip. Surge pricing punishes riders during peak demand, drivers absorb most of the financial risk, and underserved routes are deprioritized because they're not profitable enough.

Community-funded, driver-fair, transparent in pricing, and designed to serve routes that commercial platforms won't touch. Not a competitor to Bolt — a counterpart to public transit.

My Role

Validating whether a non-profit ride-hailing model is viable.

This is a self-initiated concept project. I'm responsible for product strategy, user research, and the full design process — from understanding the regulatory landscape and economic model to designing the rider and driver experiences.

The goal isn't just to design screens — it's to validate that model from a product and experience perspective, and what design decisions make or break trust in it.

The Real Benchmark

Not Uber. Not even BlaBlaCar. The incumbent is a Facebook group.

In the Baltics, the working substitute for inter-city carpooling is a Facebook group — someone posts "Tartu→Tallinn reedel 17:00, 3 kohta" and people reply in the comments. It's free, already populated, and needs no install. That's the real competitor, not the ride-hailing apps.

Two consequences follow: publishing has to feel like writing a sentence, not a multi-step form with map pickers, or people go straight back to the group. And we don't beat Facebook on trust at launch — they have real names and mutual friends, we have nobody. We beat it on matching and persistence; trust catches up later.

Research & Precedents

The playbook already exists — just not stitched together for mobility.

Before designing anything, I looked for organizations that had already solved pieces of this problem: federated infrastructure, nonprofit stewardship of shared tooling, non-extractive funding. CoopCycle is the closest structural match — a federation of worker-owned delivery cooperatives sharing one dispatch platform — and the clearest go-to-market playbook to copy: one pilot cooperative first, expand co-op by co-op.

Four more distant precedents each demonstrate one piece of the structure OpenRide needs: Framasoft and Mobilizon for foundation-stewarded, federated infrastructure; Cascade for a contribution/redistribution funding model; Open Food Network for the federated-but-locally-governed pattern working at multi-country scale over a realistic timeline.

The Model

A nonprofit foundation that never touches ride money.

A nonprofit foundation owns the codebase and sets technical direction, but never touches ride money directly. Local operators — a transit agency, a driver cooperative, a community org — each deploy their own instance, set their own commission rates, and keep what they collect. This keeps the foundation neutral instead of becoming a payments, insurance, or regulatory entity in every jurisdiction it touches.

The plan moves through three phases: bootstrap on sweat equity to land one real pilot operator, formalize the nonprofit and apply for civic-tech grants once there's a working pilot to point to, then settle into a steady mix of managed hosting, grants, and voluntary operator contributions.

A for-profit subsidiary — the Mozilla Foundation / Mozilla Corporation pattern — stays a reserved option, not a plan. It would only get created if the nonprofit structure itself became the bottleneck for hiring the engineering and security talent a safety-critical app needs, never simply because a for-profit arm could grow faster. If it's ever created, it stays wholly owned by the foundation, profits flow back to the mission, and it's contractually barred from paywalling the open-source core.

Product Structure

The mode you choose is the product — not a filter on top of it.

Every ride happens in one of three compensation modes, and that distinction is deliberately front and center rather than buried in a dropdown — an MVP that only did commercial rides would just be a worse Uber.

The bigger structural choice: planned rides come first, real-time later. Real-time dispatch needs driver liquidity that doesn't exist on day one; planned rides work with thin supply, because a driver publishes a trip they're already making and a rider requests a seat on it. That inverts the usual matching model — the system becomes an index of published trips rather than a dispatcher hunting for a free driver — and it's also the only mode where free and cost-shared rides make sense in the first place. Nobody hitchhikes across town.

One app for both roles, revised from an earlier three-app split. The case for separating rider and driver was really a dispatch requirement — always-on location, car mount, battery discipline — and dispatch is phase 2. In planned mode a driver just publishes a trip and approves requests, so one app removes a second install from the path of the casual seat-sharer who makes up the entire launch supply.

The driver counts as an occupant in the cost split, so genuine cost-sharing means they bear their own share of a trip they were making anyway — if passengers covered 100% of costs, the driver would ride free, and that free ride is the exact line where cost-sharing quietly becomes an unlicensed taxi business. Federated instances can apply a regional coefficient to the base rate, bounded to 0.8–1.25; above that ceiling the ride simply can't be cost-shared anymore.

Trust & Safety System

Getting into a stranger's car for a four-hour inter-city trip is a much bigger ask than a ten-minute taxi ride.

There's no centralized vetting in a federated network — each server checks drivers with its own rigour, and there's no corporate liability backstop behind a volunteer operator. I used a six-question trust framework (identity, reputation, predictability, safeguards, recourse, disclosure) to work through where OpenRide can and can't match Uber and Bolt, and where it has to be honest about the gap instead.

Where the Model Breaks

Federation creates edge cases no centralized competitor has to answer.

A few questions here have no off-the-shelf pattern to copy from Uber or Bolt — this is where the design work actually is.

Benchmarked Against Uber & Bolt

Copy what works, admit what doesn't, and find the one thing a federated model does better.

Open Questions & Where This Stands

This is a live concept, not a finished product — and it's honest about that.

The trust model, funding model, and rider-app scope above are worked through in real depth, but several decisions are still deliberately open rather than papered over:

• Is rating truly mandatory, or does a hard block make a bad first impression for a rider who just wants to get home?
• How much does the app track during a trip — Uber's best safety features run on continuous telemetry a privacy-first project may not want?
• Does cash make it into v1? It's the accessibility story for unbanked and older riders, and the largest dispute surface in the system.
• Does the rider get a guaranteed price, holding the quote instead of repricing at ride time — a real differentiator if it holds up?
• Is the server choice visible in the MVP at all, or defaulted the way Mastodon quietly defaults new users to one instance?
• Instant booking, or driver approval on every request? Approval fits someone vetting a three-hour passenger, but it changes whether the confirmation screen is a wait or a formality.

I probably won't build and run this in a real market — the value here is in working through whether a non-profit ride-hailing model is viable from a product and trust-design perspective, not in shipping it. The remaining driver-side screen flows and the real-time (phase 2) matching model are still being worked out.