Case study
Walk-in customers were being routed through delivery marketplaces, loyalty lived on paper stamp cards, and every menu change had to be keyed into forty tills. We built native iOS and Android ordering with a single platform behind it.
Named only with client approval Figures marked are illustrative Reply within one business day
Good morning
Your account at a glance
Balance
12,480
OlDevs built native iOS and Android apps for ordering, pickup and loyalty for a regional quick-service restaurant franchise group with more than 40 locations in Western Canada.A full-stack platform holds the menu, pricing and promotions once and pushes them to every location, while orders route into each store's kitchen display through the point-of-sale vendor's API. Loyalty points accrue on any order, in the app or at the counter, and a franchisee dashboard shows sales, redemptions and prep times by store and by hour. 31% of pickup orders are now placed in-app, and the apps hold an average rating of 4.7/5 across both app stores.
Key facts
The challenge
Franchisees were paying third-party delivery commissions on orders that started as walk-ins, because the group had no ordering channel of its own. The loyalty programme ran on paper stamp cards that could not be tracked or audited, and there was no single view of what was selling where. Every menu change had to be keyed into each location's till by hand.
Customers who fully intended to collect in person ordered through delivery marketplaces, because that was the only app the group appeared in. Each of those orders carried a commission the franchisee paid on a sale the brand had already won.
Paper stamp cards left nothing to track or audit. No one could tell which offers actually brought customers back, and head office could not reconcile what a location had given away against what it had sold.
A price change or a new item meant somebody keying the same edit into every location's point-of-sale terminal. Rollouts took time, stores drifted out of step, and a promotion could be running in one town and missing in the next.
With no single view of what was selling where, the group had no reliable way to compare one location against another. A question as basic as which items sell best mid-afternoon had no straightforward answer.
What we built
We built native iOS and Android apps for ordering, pickup and loyalty, backed by a full-stack platform that holds the menu, pricing and promotions once and pushes them to every location. Orders route straight into each store's kitchen display through the point-of-sale vendor's API, and loyalty points accrue on any order, whether it starts in the app or at the counter. A franchisee dashboard shows sales, redemptions and prep times by store and by hour.
Both apps are built natively, so ordering, payment and pickup timing behave the way each platform expects. Menus, modifiers and store hours come from one source, and the apps handle a closed store or a sold-out item without dead ends.
Head office edits an item, a price or an offer in one screen and it reaches every location. Publishing is scheduled and reversible, so a regional promotion can start at opening and end at close without anyone touching a till.
Orders pass through the point-of-sale vendor's API into each store's kitchen display and land in the same queue as counter orders. Staff do not learn a second system, and prep time is measured from the moment the ticket appears.
Points accrue on any order, in the app or at the counter, against a single customer record. Redemptions and issued value are recorded per store, so franchisees and head office reconcile the same numbers instead of counting stamps.
Process
Pilot store chosen first
We picked one location as the pilot and worked with its manager from the start, because the people running service at the counter had the sharpest view of where an ordering flow would break.
Point-of-sale integration proven early
We built and tested the point-of-sale and kitchen display integration before the apps were finished, so the dependency most likely to shape the design was settled while there was still time to design around it.
Working builds from week six
Test builds went to the pilot store from week six. Staff and regulars used them during real service, and the ordering flow changed on what happened at the counter rather than on what we assumed at a desk.
Rollout region by region
Locations came online in regional waves, each trained on a real app rather than a slide deck. Platform, integration and support load were proven at one scale before the next wave started.
Franchisee reporting and handover
We built the dashboard around the questions franchisees were already asking, then handed over the code, the app store accounts for both platforms, and the runbooks the group needs to operate it.
Stack
iOS app
Android app
Platform and data
Integrations
Delivery and operations
31%
Of pickup orders now placed in-app
4.7/5
Average rating across both app stores
1 screen
To publish a menu change to every location, down from 40+ tills
Outcomes
31% of pickup orders are now placed in-app, on a channel the franchise group controls rather than rents. Orders that begin as walk-in intent no longer have to travel through a marketplace to reach the kitchen.
The apps hold an average rating of 4.7/5 across both app stores. For a business that lives on repeat visits, a rating people keep returning to matters more than an install count.
It now takes 1 screen to publish a menu change to every location, down from 40+ tills. Pricing, availability and promotions are consistent across the network on the day they are meant to be.
Sales, loyalty redemptions and prep times are reported by store and by hour from the same data, so conversations at the franchise level start from an agreed picture rather than from reconciling spreadsheets.
In their words
The pilot store's manager asked when the other locations were getting it, which told us more than any dashboard could.
Director of Operations, regional franchise group
Food service & franchising
FAQ
Ordering is a speed and trust problem. Native iOS and Android give predictable payment sheets, push behaviour, accessibility and background handling, and they let each app follow the conventions its users already know. For a repeat-purchase app used in a short window before pickup, that difference shows up in how many orders get finished.
That is the first thing we test. In this build, orders route into each store's kitchen display through the point-of-sale vendor's API, so staff work one queue rather than two screens. We prove the integration early in the engagement, before the apps are finished, because it is the dependency most likely to shape the design.
One pilot store first, from week six, with real customers and real service. After that, locations came online in regional waves so each group of managers trained on a working app and the support load was proven at one scale before the next. The full engagement ran 22 weeks.
Yes. Points accrue on any order against a single customer record, whether the order starts in the app or at the till, which is what makes the programme worth joining for customers who sometimes just walk in. Redemptions and issued value are recorded per store so franchisees can reconcile them.
The client does. On every OlDevs engagement the client owns all code, designs, accounts and intellectual property, including the app store accounts for both platforms. We hand over repositories, infrastructure definitions and release runbooks so the group can keep shipping without us.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.