Craveable Brands
Evolving the online ordering platform behind Red Rooster, Oporto and Chicken Treat.
What started as a small piece of frontend work became a long-term relationship spanning ordering, payments, delivery, mobile, loyalty, restaurant operations and the architecture connecting it all.
We didn’t build the platform.
We inherited it.
42 Interactive originally came in to help with a relatively small piece of React frontend work. The platform behind it was anything but small.
The original delivery team had largely moved on, taking much of the knowledge of the system with them. We had some handover, but not enough to understand a platform of this size.
There were around 170 microservices, native iOS and Android applications, a React ordering experience, serverless infrastructure on AWS, DynamoDB, multiple delivery providers, loyalty, payments, menus, POS integrations and a long list of dependencies between them. Serverless was relatively new to us too.
So we were learning the technology, reverse-engineering the platform and shipping production work at the same time.
The first deployment didn’t go particularly well. Our CI/CD run broke the platform and former developers had to help us recover it.
It was an uncomfortable introduction. It was also the beginning of understanding the system properly.
So I went to work in one.
Looking at the architecture told me how the software was connected. It didn’t tell me how a restaurant actually worked.
I asked Craveable if I could spend time inside one of their stores. I went to Lakemba and worked alongside the team.
I watched orders arrive. I learned how the POS interacted with the Kitchen Display System. I watched the different food preparation stations.
I saw how orders were packed, how drive-through worked, how delivery drivers arrived, and what happened when the systems didn’t behave the way the software assumed they would.
I spoke to the people actually using the platform. That changed my understanding of the problem.
Things that looked like software issues were often operational issues. Things that looked sensible in an architecture diagram didn’t always make sense when there was a queue of cars outside and food waiting on a counter. And small technical decisions could affect whether someone’s dinner arrived hot.
The architecture made more sense
once I understood the kitchen.
17 things I thought we should change.
That time in the restaurant changed how I looked at the platform.
In August 2021, we consolidated what we’d learned into a set of recommendations for OLO.
The objective wasn’t architectural purity.
It was to increase orders.
That meant looking at the system through three lenses:
- 01
Driving more traffic.
- 02
Increasing conversion.
- 03
Increasing retention.
The recommendations ranged from reliability and failed-order handling through to delivery timing, customer accounts, operational visibility, store experience, SEO, testing, payments and bringing the three brands onto one platform.
Some were small. Others became major engineering programmes. Most would eventually be implemented.
An order touches a surprising amount of software.
The recommendations sounded straightforward on paper. Implementing them wasn’t.
Ordering a chicken burger looks simple from the customer’s side. Behind it sits a distributed system coordinating stores, products, menus, pricing, vouchers, payments, loyalty, delivery providers, restaurant systems and the applications customers interact with.
A product can have different prices by store. Pickup and delivery behave differently. Menus have to remain synchronised with restaurant systems.
An order can pass through several systems before it appears on a kitchen screen. And payment succeeding doesn’t necessarily mean the restaurant successfully received the order.
That last distinction became particularly important.
~580Restaurants
1M+Customers / week
And this wasn’t a system we could casually experiment on.
At this scale, small architectural decisions become operational decisions.
Payment success isn’t order success.
One of the first major problems we tackled was failed ordering.
The platform could successfully take a customer’s payment and then fail while pushing the order through the restaurant integration.
From the customer’s perspective, that’s about as bad as ecommerce gets: you have my money, but the restaurant doesn’t have my order.
Historically, those failures could require someone to identify the problem and manually refund the customer.
We changed the payment flow to use pre-authorisation. Instead of completing payment before knowing the order had made it through the critical parts of the journey, the platform could authorise the funds and complete or release them based on the outcome.
It required significant changes to the ordering flow.
But the important change wasn’t technical.
Failure became something the architecture expected rather than something support had to clean up afterwards.
2.6%
Fewer fraudulent transactions
Payments evolved elsewhere too.
In a separate initiative, integrating Forter through the Fat Zebra payment gateway reduced fraudulent transactions by 2.6%.
Failure isn’t an edge case in a distributed system.
It’s part of the design.
Software can decide when the chips get cooked.
Payments weren’t the only place where software decisions reached into the restaurant.
Delivery made that relationship even more physical.
At the time of our original recommendations, average delivery time was just over 36 minutes. The target for food quality was under 30.
One of the biggest sources of delay was the relationship between when a restaurant started preparing an order and when the delivery driver actually arrived.
Prepare it too early and the customer gets cold food. Prepare it too late and the driver waits.
We worked with DoorDash’s Automatic Order Release capability so the driver’s proximity to the restaurant could help determine when the order was released to the POS and kitchen.
The aim was simple: have the food reach the counter as the driver reaches the restaurant.
- Driver approaches
- Order released
- Kitchen prepares
- Driver arrives
Hotter food.
Delivered faster.
The marketing site and the ordering site were solving the same customer journey.
Not every boundary in the platform was a microservice. Some were visible to the customer.
Red Rooster effectively had two websites.
The brand and marketing experience lived in WordPress. The ordering application lived separately in React.
The arrangement made technical sense historically, but it created a break in the customer journey.
The marketing site was good at attracting people. The ordering site was good at taking orders. Neither had the full context of the other.
It also limited SEO — much of the useful product, menu, store and pricing experience lived inside the ordering application rather than the site search engines understood best.
We recommended bringing them together.
The eventual solution moved the web experience to Next.js and introduced Contentful as the headless content platform.
Marketing content and ecommerce could now exist inside the same application. A campaign could lead directly into an order, while store and menu content could participate in the wider web experience.
And the customer no longer had to cross an architectural boundary simply because they pressed ‘Order’.
3%4.5%+50%
Online conversion
3% → 4.5% represents a 50% increase.
Publicly reported as an outcome of the SEO and UX work behind bringing the two experiences together.
One platform.
Three brands.
As the platform evolved, Red Rooster was no longer the only brand we needed to think about.
Oporto and Chicken Treat had ordering implementations based on forks of the original code. Over time those codebases diverged. Different brands used different delivery providers, business rules differed and features evolved independently.
Every platform-wide change risked becoming three pieces of work.
We brought the codebases back together.
Where brands genuinely behaved differently, the difference became configuration or a provider rather than another fork.
One brand could use Uber while another used DoorDash, while both operated through the same underlying platform.
Shared where possible.
Different where necessary.
The goal wasn’t to make the brands identical. It was to make difference intentional.
That decision paid off repeatedly. When payment infrastructure changed later, we could implement the new provider against the shared platform rather than rebuild the capability three times.
Mobile followed a similar path, moving from separate native iOS and Android implementations toward a shared React Native codebase.
A platform never stops changing.
The platform never stopped changing because the business never stopped changing.
COVID brought kerbside collection and drive-through ordering into the digital experience. Payments evolved. Delivery evolved. Mobile evolved. Testing and observability improved.
And beneath all of it was the less glamorous work that mattered just as much: supporting production, investigating failed orders, deploying releases and keeping a national ordering platform running.
- 01
Inherited OLO
- 02
Restaurant research
- 03
Ordering resilience / Pre-auth
- 04
Kerbside + drive-through
- 05
Recommendations
- 06
Brand + ordering site merge
- 07
Multi-brand consolidation
- 08
React Native
- 09
Apple Pay + Google Pay
- 10
Delivery evolution
- 11
Automated testing
- 12
Payment platform migration
The tools changed.
The job didn’t.
Over the years almost every layer of the platform changed.
Frameworks changed. Payment providers changed. Delivery providers changed. Mobile architecture changed. The way we deployed and tested changed.
But the most useful thing I did at the beginning had nothing to do with a framework.
I went into the restaurant and watched.
Architecture gets easier when you understand the system.
Product decisions get easier when you understand the people using it.
And technology decisions become clearer when you understand what happens when they reach the real world.