A new ordering platform, the same app. Every guest moved over in five days.

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.

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.

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.

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 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.