This study presented the results of an independent evaluation of the Regional Transportation Authority (RTA) of Pima County Adaptive Mobility with Reliability and Efficiency (AMORE) Mobility on Demand (MOD) Sandbox Demonstration implemented in the Tucson, Arizona metropolitan area. This study involved improvement of the existing fixed-route transit system in terms of reliability and efficiency and increasing ridership while delivering a seamless user experience. The evaluation involved exploring 10 hypotheses surrounding the project’s impact on travel behavior, user experiences, and costs. The AMORE pilot ran from October 2018 to May 2019, emphasizing the creation of a financially viable mobility network. This included the launch of a subscription-based, app-accessible transit service named RubyRide, offering a cost-effective solution for daily commuting and connecting to other public transportation. The initiative aimed to improve usage and capacity, and to integrate community-driven carpooling seamlessly. In August 2019, a series of interviews with stakeholders and project partners were conducted, gathering insights from the pilot's execution. Participants included the Pima Association of Governments, various private transit providers, transportation technology firms, and RubyRide. 

The interviews revealed key lessons learned from the pilot project related to service area selection, labor, insurance, marketing, Wheelchair-Accessible Vehicles (WAVs), and technical challenges, including the onboarding process.

• Allocate labor wisely considering the trade-off between cost and service reliability when operating shared ride modes in low-density and off-peak service environments. Transportation Network Companies (TNC) serving lower-density and rural areas are often unreliable and have a high likelihood that no drivers will be available. In this study, to overcome this reliability challenge, drivers were hired and paid on an hourly basis, which kept a certain number of drivers on-call but led to the depletion of funds more quickly than if drivers had been dispatched and paid on a per-trip model.
• Select a service area with the purpose of developing a service to meet an unmet mobility need. In this study, the selected service area led to some challenges during the pilot implementation, since a small service area was selected with the goal of designing a service that replaced the existing fixed-route service, rather than considering the travel demands, and major origins and destinations while deciding on the service area. 
• Recognize potential technical challenges, big or small. This study revealed lessons about addressing small technical challenges during early rollout, such as trip dispatch issues and Android-specific app problems. It highlighted the importance of accurate geocoding within the service area for efficient user location setting. The onboarding process emphasized the need for alternative payment methods for users without credit or debit cards, although this feature was not widely used.
• Be aware of challenges in getting insurance when operating a TNC-dependent service. In this study, insurance was a notable challenge that delayed the project since the insurance companies were hesitant to insure the TNC model where drivers were using their own vehicles. Eventually, a third-party application that uses smartphone sensors and algorithms to predict risk, and shares these data with the insurance provider was integrated into the insurance process to get the insurance provider company on board, which added an additional six months to the project timeline.
• Emphasize marketing with education and outreach efforts through multiple stakeholders to eliminate any preconceived notions of the public about TNCs. A multifaceted community engagement strategy was employed, including diverse outreach methods and targeted media campaigns. Challenges were faced in digital marketing due to the project's limited geographic scope and small population size. 
• Acquire WAVs only if no other options exist. In this study, WAVs were leased from a third party to be added to the RubyRide system. However, it was challenging in attracting WAV users, likely due to the existing preference of users for the familiar local paratransit provider.