# Scooter’s Coffee Moves Mobile Ordering to Olo Without Changing the Guest Experience > VGV helped Scooter’s Coffee replace its menu and mobile-ordering platform with Olo in the middle of a Flutter rebuild, and moved every app user to Olo ordering in five days. - Source: https://verygood.ventures/success-stories/scooters-coffee-olo-ordering/ - Client: Scooters Coffee - Industry: Food & Beverage - Services: Engineering --- A new ordering platform, the same app. Every guest moved over in five days. Scooter’s Coffee chose Olo to replace its menu and mobile-ordering platform while we were rebuilding its apps in Flutter. We joined the team to make the switch behind the scenes, kept the guest experience the same, and moved every app user to Olo ordering in five days. - **5 days** from 25% of Android users to everyone - **99.98%** app uptime ## The ask: Swap the ordering platform. Keep the app guests know. Scooter’s Coffee was partway through [rebuilding its mobile apps in Flutter](/success-stories/scooters-coffee/) when the plan for the ordering layer changed. The rebuild assumed Scooter’s existing ordering platform would keep powering menus and mobile orders. Then Scooter’s chose Olo to replace it. That added a second migration inside the first one. Guests would keep ordering from the same app while the platform behind every menu, basket, and order changed underneath them. Scooter’s didn’t want a redesign or new menu features. It wanted the app guests already knew, running on a different ordering provider. **The catch:** Olo replaced the ordering layer, not the in-store point-of-sale system. Every order still had to land in the POS that Scooter’s stores already ran, while payments and loyalty stayed where they were. ## The approach: Put the change in the backend, not the app. We put most of the adaptation in Scooter’s backend instead of the Flutter client. The backend absorbed Olo’s data model and API, and the app kept talking to an interface it already understood. Fewer client changes meant less risk to a Flutter rebuild that was still in flight. We were precise about the boundary. Olo took over menus and mobile ordering, and became the layer that sends orders into the existing POS. Holding that line kept the team from solving problems that belonged to a different system. ## The scope: Three areas moved to Olo. Two stayed put. Store and menu data moved first. New Olo clients handle restaurant lookup, nearby-store search, menus, products, sizes, and nested modifiers. Cart and checkout followed, with separate operations to add, update, and remove products and set tips. The basket validates against the POS before Olo accepts the order. Migration infrastructure tied it together. An Olo feature flag, restaurant-cache updates, favorite-store ID migration, and provider-aware routing let the team switch providers without losing saved guest data. Payments and loyalty stayed in place. Scooter’s kept charging cards through its existing payment processor, and Olo receives each order as prepaid. Scooter’s also kept its existing loyalty platform instead of rebuilding loyalty rules inside Olo. That limited disruption for guests, and it meant three systems had to agree on every order. ## The hard part: Loyalty discounts had to reach the tax line. One month from launch, a loyalty issue became a release blocker. The loyalty platform calculated a guest’s discount correctly, but the discount didn’t pass through Olo. We weighed a backend tax workaround. It would have fixed the guest’s total, but Olo’s franchisee dashboard would have shown numbers that didn’t match what guests paid. Store owners rely on that dashboard, so the workaround would have traded one problem for another. The fix came from configuration, not code. Olo switched the channel’s coupon-provider setting to a legacy option in both sandbox and production. That setting enabled open-dollar discount passthrough without any change to the POS. Our team then retested the full flow against the new setting. ## Under the hood: Matching item IDs, and planning for calendar time. Olo’s menu identifiers didn’t match the POS item IDs that the loyalty platform’s rules depended on. Without a match, a reward couldn’t find the item it applied to. The team agreed on a mapping table in Scooter’s backend that links each Olo identifier to its POS and loyalty item IDs, populated initially through Olo’s Operations API. A recurring, automated mapping is a longer-term request to the vendor. Early planning separated two numbers. The engineering estimate was short. The calendar timeline was much longer, because vendor responses, configuration, and cross-team testing set the pace. POS behavior was the area with the least control, and QA capacity was the tightest constraint. Naming those limits up front kept the schedule honest when vendor-side issues like the discount setting surfaced. ## The rollout: Every store ready first, then a staged release. The production checklist ran in a fixed order. Olo configuration, feature-flag activation, deployment, a restaurant-cache refresh, and favorite-store migration all closed before the switch. The app stores decided who got the new version, not us. A staged release goes out by user, so we couldn’t choose which stores saw Olo orders first. Every store had to be ready to work with Olo before the rollout began. The release started with 25% of Android users. Five days later, it had reached everyone on Android and iOS. That step ended Scooter’s dependence on its previous ordering platform. > We are really happy with the attentiveness and the professionalism [VGV’s] people are putting into our app. I know people care about it and they’re invested in it. And it’s probably why we were able to turn around such a good clean app so quickly. > > Andy Henrichsen, Director of Enterprise, Scooter’s Coffee ## What changed: Same app for guests, new platform behind it. - **Five days, From 25% of Android users to everyone.** The staged release reached every Android and iOS user five days after it started. - **99.98% uptime, The app stayed up through the switch.** Guests kept ordering from the same Flutter app, which runs at 99.98% uptime. - **Same experience, Guests kept the app they knew.** Menus, carts, payments, and loyalty looked and worked the way they did before the migration. - **One ordering layer, Olo now sends every order to the POS.** Scooter’s no longer depends on its previous ordering platform, and its in-store POS stayed in place. The launch moved every store to Olo but it didn’t close every operational issue. After go-live, the team worked through incorrect store coordinates, stores missing from search, out-of-stock items and modifiers, unclear checkout error messages, and isolated blank orders on POS and kitchen display screens. New stores also needed manual Olo setup for tips and public visibility before guests could find them. A provider swap touches every store’s data, and some of that data only shows its problems under real traffic. Budgeting stabilization time after launch is part of the work. It isn’t a sign the launch went wrong. ## If you’re next: What we’d tell a team in Scooter’s seat. - Decide what the guest should never notice, and push the change behind that line. - Be explicit about which systems you’re replacing and which you’re only reconnecting. - Plan for the places where those systems have to agree. That’s where the schedule goes. - Separate the engineering estimate from the calendar timeline, and budget time to stabilize after launch. ## Roll credits - **Client:** Scooter’s Coffee - **Our part:** Olo integration, Backend migration, Flutter app, Rollout support - **Platforms:** iOS and Android - **Built with:** Dart, Flutter, Olo - **Rollout:** Five-day staged release on Android and iOS ## Frequently asked questions. ### Did Olo replace Scooter’s point-of-sale system? No. Olo replaced the menu and mobile-ordering platform. It became the ordering layer that sends orders into the in-store POS that Scooter’s stores already ran. ### Did guests see a different app after the move to Olo? No. The goal was to keep the guest experience the same. Most of the adaptation lived in Scooter’s backend, so the Flutter app kept talking to an interface it already understood. ### How did the rollout to Olo work? Through a staged app store release. It started with 25% of Android users and reached everyone on Android and iOS five days later. The app stores choose which users get a staged release, so every store had to be ready to work with Olo before the rollout began. ### What was the hardest part of the Olo integration? Getting loyalty discounts through Olo so tax was calculated on the discounted total. Olo resolved it with a channel configuration change, which kept the franchisee dashboard consistent with what guests paid.