Case—Calyber: A Ridesharing Game

1. Introduction

Eliot George is the CEO of Calyber, a ridesharing company based in Chicago, Illinois. When he founded Calyber several years ago, Eliot was driven by a firm belief: to truly succeed, Calyber must offer shared rides—where each driver transports multiple compatible passengers in a carpool-like service. Having grown up in Los Angeles, Eliot was all too familiar with the frustrations of traffic congestion. This experience deeply shaped his vision for Calyber. He was fond of saying that if the company failed to achieve a high level of ride sharing, it would be no different from a traditional taxi service—just one with a slick mobile app.

But offering a profitable shared rides service had turned out to be more difficult than he had once imagined. Downtown, Calyber kept prices low to attract customers. But prices were so low that even with most riders matching with compatible coriders, Calyber was unable to recoup its dispatching costs. Outside of downtown, prices were higher, but this caused separate issues. Most riders who booked a shared ride were never matched with compatible coriders; meanwhile, those who did share were often sent on long, costly routes picking up coriders all over the city. This had turned Calyber into the butt of jokes on social media, as vocal customers complained about irritating coriders and long detours. (Customers with positive experiences rarely posted on social media, Eliot noted with some chagrin.)

Faced with these challenges, Eliot decided to discuss a way forward with Calyber’s chief scientist, Thea Bruckner. He hoped that together, they could design a shared rides product that could achieve high ridership and profitability at the same time.

2. Background

A ridesharing platform is a transportation service provider that connects customers (riders) with drivers who can take them from their origins to their desired destinations, usually via a mobile app.

Lyft was founded in 2007 by Logan Green and John Zimmer as an intercity carpool service between college campuses before shifting in 2013 to short-distance rides (Sherman et al. 2019). Uber was founded in 2009 by Travis Kalanick and Garrett Camp after they had difficulty hailing a taxi in Paris and sought to make the experience as simple as pushing a button on a smartphone (Uber 2025).

Initially, both companies focused on solo rides, similar to a taxi service. This changed in 2014 when both companies (within a day of each other!) launched shared rides in San Francisco (Anand 2017). The products, dubbed UberPool and Lyft Line, offered riders lower prices in exchange for potentially sharing the ride with other riders in a carpool-like service. The idea was that multiple riders with compatible origins and destinations could be served concurrently (matched) with the same driver, reducing vehicle miles and improving efficiency. As Kalanick put it, “We saw a lot of people pushing the same button at the same time going essentially to the same place. And so we started thinking about, well, how do we make those two trips and turn them into one?” (Kalanick 2016). The platform would benefit by serving more riders at lower cost, riders would benefit if lower costs translated into prices low enough to make them willing to share, and Zimmer even claimed that vehicle miles would be reduced so much as to enable the “end of traffic” (Zimmer and Green 2017).

Within a few years, the new shared rides products became core offerings, comprising 20%–30% of all rides (Lunden 2016, Lyft 2018). In 2018, Uber doubled down on shared rides and launched Uber Express Pool, a low-cost variant of UberPool that charged riders low fares in exchange for walking toward meeting points with other riders (Uber 2018). At the same time, Lyft announced its ambition for 50% of its rides to be shared by the end of 2020 (Lyft 2018).

However, operational challenges have prevented shared rides from living up to their lofty aspirations. After the launch in 2014, both companies sought to “win” riders in San Francisco, chiefly by keeping prices low—Uber even offered a $5 flat fare.¹ But at the same time, Uber’s algorithms struggled to match riders: the match rate, or the fraction of riders who get matched with another rider, was reportedly only 8%. The combined effect was that Uber was essentially offering ultracheap solo rides, a practice that lost $1 million a week and that was subsequently described as “bleeding cash subsidizing rides [without] a plan for tomorrow.” Over the next few months, Uber improved its matching algorithms and achieved a match rate of almost 25%.² But this improvement was still not enough to break even. Attempting to cut its losses, Uber raised prices, which then tanked ridership by 22% (Anand 2017).

Compounding these difficulties, the COVID-19 pandemic compelled both companies to shut down shared rides entirely to aid physical distancing. Recognizing the difficulty of bringing customers back to shared rides, Lyft’s and Uber’s relaunches in 2021 and 2022 came with a strong emphasis on affordability for inflation-conscious customers. Lyft included an option to reserve shared rides early for an extra discount, promising “the most affordable pricing available” (Lyft 2021). Meanwhile, Uber launched a pricing policy that would offer further discounts to riders if they were matched with coriders. As Uber CEO Dara Khosrowshahi explained, “You get a deeper discount if you get matched up with somebody, so it’s in your interest to get matched up… taking that sharing to the next level and the discounts to the next level” (Uber 2022, Morning Brew Daily 2024). However, these launches struggled to find traction (Desai 2022), and in the face of financial difficulties, Lyft stopped offering shared rides in 2023 (Davalos 2023). Announcing the decision, Lyft CEO David Risher explained, “The problem with shared trips is that they take people out of their way. At some point you have to pay attention to what your customers want.”

The up-and-down history of shared rides highlights the following operational challenges. First, matching requires multiple riders with compatible origins, destinations, and request times, which can be rare unless demand density is sufficiently high. Second, low prices are needed to attract riders and achieve enough density for efficient matching, but can create losses for the platform if riders cannot be matched effectively. In trying to strike a balance, platforms may set prices that are both too high to attract riders and too low to comfortably sustain. These operational challenges fuel skepticism that shared rides can be operated viably.

At the same time, these challenges present an opportunity for any ridesharing company that can solve the puzzle of a viable shared rides product. In 2025, Uber promoted new features called route share and price lock, aimed at making regular trips (e.g., to and from work or major events) more affordable to combat continued inflation and improve accessibility (Jackson 2024, Kansal 2025, The Verge 2025). Lyft also started experimenting with shared rides again, reintroducing them at airports with high demand density (Lung 2025). Moreover, beyond the high-density corridors formed by commutes, major events, and airport trips, low-density neighborhoods are an underserved market primed for innovation.

3. Calyber’s Operations

Calyber is based in Chicago, Illinois, and focuses entirely on offering shared rides (see Figure 3 for its service area). Its platform is used by about 35,000 customers per day. The service is on demand, which means that riders can expect to be served quickly. Calyber might let riders wait on the platform to give time for compatible coriders to arrive, but this waiting time is kept short (e.g., at most a few minutes) to ensure customer satisfaction. Calyber also guarantees that each rider will be matched with at most one other corider.

To request a ride, a rider can open Calyber’s mobile app, enter the origin and destination, and receive a price quote (this is called a rider session). If the rider is willing to pay the quoted price (the rider decides chiefly based on the price per unit distance in dollars per mile), then the rider requests a ride. Otherwise, the rider leaves the platform. The rider’s willingness to pay is unknown to Calyber.

After a rider makes a request, Calyber makes a dispatch decision. If there is another compatible rider currently waiting on the platform, Calyber can match the two riders and dispatch them immediately on a shared ride. Otherwise, Calyber can let the rider wait on the platform for a short period. The rider has limited patience, so she is willing to wait only for a limited sojourn time, which is also unknown to Calyber. If the rider’s patience expires, then, as the rider is about to exit the platform, Calyber can intervene and dispatch the rider immediately in a solo ride. See Figure 4 for example routes corresponding to shared and solo requests. Whether the dispatch is shared or solo, Calyber pays the driver $0.70/mile to perform the dispatch. As Calyber is known to treat drivers well, there are sufficient drivers to ensure that a driver is available for immediate dispatch.

A critical feature of shared rides is that the average cost per request depends on demand density. When demand density is high (i.e., more riders request similar trips at similar times), it is easier to find matches with low detours. Then, a single driver can serve multiple requests with only slightly longer routes, reducing the average cost per request. By contrast, when demand is sparse, it is more difficult to find matches. Consequently, the platform dispatches more requests along routes with longer detours or even solo, increasing the average cost per request.

4. A New Engine for Pricing and Matching

Calyber’s pricing and matching engine had been designed by one of its founding engineers, Nick Bailey. Unfortunately, Nick was no longer at Calyber, and the engine was a black box to the rest of the engineering team (hastily written code from the early years of a startup is not known for tidiness).

Eliot and Thea agreed that Calyber could not address its operating issues without overhauling its pricing and matching engine, and they decided to discuss the best way to move forward.

• Eliot: The shared rides product isn’t working for us—we’re bleeding cash.³ I think we need to raise prices. And it seems that the engine is pretty complicated and has caused your team a lot of trouble. What if we simplify and charge everyone a flat price, like $0.80/mile?

• Thea: I agree that we should raise prices, although we should be careful not to drive away riders. As for the flat price, I see the appeal of simplicity, but I don’t think charging different riders different prices is the problem. Actually, charging different riders different prices can be a good thing. Downtown riders are matched more than the riders in the outer neighborhoods, so they cost us less per mile. Shouldn’t they get lower prices?⁴

• Eliot: What do you think is the problem with the engine, then?

• Thea: To me, the problem with the engine is that its pricing decisions are completely black box. It’s impossible to troubleshoot. Remember a couple weeks ago, when a bug made it into production, and we tanked the price of airport rides for an entire weekend? It took my team days to track down the issue.

• Eliot: Yeah, we need to make sure that this kind of mistake never happens again. That’s one reason why I proposed a flat price for everyone. But you made a good point just now—different riders cost us different amounts per mile. So, what about pricing at cost? It seems like we could at least differentiate downtown and outer riders.

• Thea: We can model costs at an even more granular level than downtown versus outer. We record every route that our drivers take, including all rider pickups and drop-offs. We can easily use the routes to calculate the average cost by origin and destination.⁵

• Eliot: Great. What do you think riders will think of our pricing strategy?

• Thea: That’s another piece we should figure out. Every time a rider uses the mobile app, we record the origin, destination, price, and whether the rider makes a request.⁶ We could use this historical data to learn how riders respond to our prices and build a demand model. Combining the demand model with the cost model, we can set prices that maximize profit.

• Eliot: This sounds good to me. So, pricing is resolved then. What will we do about matching, then?

• Thea: There’s so much to do on the pricing side that I haven’t thought about matching yet. I’m hoping that we’ll have enough customers that we won’t have to worry so much about matching. Then we could do something simple. Say a rider has just made a request on the platform. If there are no compatible coriders waiting for dispatch, then let the arriving rider wait. But if there are compatible coriders waiting on the platform, then match the arriving rider with the waiting rider that generates the highest level of cost saving in their shared route.

• Eliot: That sounds reasonable to me. Why would we ever match any other way?

• Thea: Well, it’s possible that if we let the arriving rider wait even longer before we dispatch, then other compatible riders might arrive, and we might be able to find better matches. But by waiting, we also risk riders trying to cancel their rides if we make them wait too long.

• Eliot: Waiting can be valuable, then. You talked about using historical data to understand how riders respond to prices. Can we also use it to understand how they feel about waiting?

• Thea: Maybe… We do record riders’ waiting time from arrival to dispatch in our database.⁷ But we’re missing some information—for riders who are matched with other riders, we don’t know how long they would have waited otherwise. I think this would be difficult for us to do right—we already have a lot to do on the pricing side, and my team is stretched pretty thin. Why don’t we focus on getting a simpler prototype up and running and work on this waiting idea later?

• Eliot: I see. I do like the idea of giving customers fast service, so let’s go with your first idea.

• Thea: Sounds great to me. We’ll get started right away on implementing the new engine, and we’ll kick off an experiment to track profit, match rate, and throughput.

• Eliot: Sounds like a plan.

Thea’s team implemented the new engine and piloted it in an experiment.⁸ Thanks to an increase in prices, profit increased—instead of losing $3.76 per minute, Calyber was now making $2.47 per minute in profit. Thea was happy that the new engine was profitable but suspected that there was still room for improvement. Throughput had dropped by 76%, from 16.82 to 4.02 riders per minute. As a result, the match rate dropped from 80% to 59%.

Thea wondered if they had raised prices too quickly. Should they back off the higher prices? If so, were the demand and cost models accurate enough to quantify the impact of such a pricing change? And could they do anything else to increase demand beyond simply adjusting prices up and down? Finally, if they did have to keep prices at the higher levels, could they improve match rates with the existing throughput? She called a team meeting to discuss these questions and chart a path forward.

Table 1. KPIs for Nick’s and Thea’s Pricing and Matching Engines by Neighborhood Type

Table 2. Sample of Calyber’s Data on Routes Taken to Fulfill Rider Requests

Table 3. Sample of Calyber’s Data on Rider Sessions