GRUBHUB by ARE TOO.
Designing and developing a new enterprise brandable web sdk for one of the worldβs largest online ordering platforms
THE GOAL
For Grubhub to offer a brandable online ordering solution for large restaurant chains.
Grubhub is an online ordering food marketplace usually associated with delivery from mom-and-pop shops and small to medium restaurant chains. 100+ location fast casual and quick service franchises are often looking to customize and brand their online ordering experience, therefore, working with Grubhub was not seen as an option.
-
Native vs. Responsive Web, or both?
Grubhub Agency, previously known as LevelUp (weβll refer to them as Grubhub going forward), had only ever built native apps. Focusing on restaurants as of 2013, they were the pioneer in the space that built Sweetgreenβs native branded payment app. The app changed the role and demand of tech in the restaurant industry. Since investing all of their time and money in native, and building out their Android and iOS SDKs, Grubhub had always perceived agency web apps to be competing for sales with their native apps. It also didnβt help that like most tech companies, Grubhub was under-resourced, contributing to the decision to not venture into new product territory.
Desktop and Web
Grubhub Agency users place orders mainly during the βlunch rushβ between 11:30am and 1:30pm. However, the typical user is sitting at a desk during these times in front of a laptop or a monitor. Businesses like Dig Inn and Potbelly Sandwiches had been investing in their own agencies to build desktop experiences despite having separate iOS and Android apps integrated with Grubhubβs API. So, why were they paying an agency to build a separate web app?
Web is easier to maintain: deployments donβt require wait times or approval from app stores
Web can be less expensive: native often implies the support of two complex platforms, iOS and Android, that require two specialized development teams
Most users donβt want to download native apps for every restaurant
Web is available across multiple platforms and on most devices (like TVs and tablets)
Tech taking over restaurants
The push for a tech transformation in the food industry was relatively new and there are now expectations of digital payment, online ordering and loyalty (not in archaic punch card format). It is expensive and time-consuming to build a new product, especially for restaurants, when restaurant operations are costly and tech is perceived as a small piece of business. Therefore, it made complete sense to build this cost-effective, branded and responsive product.
-
Door Dash, Postmates, UberEats, Punchh, Olo, Revel, Toast, should we go on? While some competitors are food ordering marketplaces and some are direct competitors that also develop semi-custom apps and branded UIs, tech capabilities in the food industry are endless
The leg up for Grubhub? Having a feature-filled platform (loyalty, payment, reloading funds, gift cards, integrations, and more), and their success in attaining customers (via their SMB product).
As a result of Grubhubβs existing client roster and having a majority in customer market share, the web SDK product would also allow for a single login across all restaurants.
-
Brainstorming and Sketching
We downloaded a myriad of ordering apps such as:
Paneraβs app - known for its customer journey and UX
Sweetgreenβs app - touted for its silky interactions
Chick-fil-Aβs app - highlights a visual order customization UI
Door Dash - great map view UX
After conquering the world of research by reviewing our data, studying UI trends, mapping user journeys, scanning competition, and trusting our UX instincts, we began sketching a rough idea of each screen. To us, sketching should consist of endless annotation and expectations of that screenβs features.
Wire-framing and Prototyping
We hashed out the UX on our whiteboards and from there started wire-framing, checking in with the team to review the UIs and interactions of individual elements, like hovers, clicks, and empty states. We went through eleven rounds of designs until all UI elements and UX decisions were approved. Many UX decisions (like the account side nav) were removed for scalability and UX reasons.
Brief Code Overview
The code base consists of React components and config files to specify layouts, menu IDs, app IDs, language, copy, default styling, and more.
All components have associated styling variables (such as border-width, line-height, font-size and drop-shadow).
When creating a repository for a new client, any SASS changes to a variable, edits in copy, and modifications to the config files overrode the base SDK.
The SDK took about two months to design from sketching to approved wireframes. We also took on all front-end development work for styling the first round of clients: Burger21, fresh&co, Chase Pay, Honeygrow, Minigrow, and more.
Since Grubhub Agency had never focused on web, there was no full-time full-stack developer; we quickly learned we needed to build a team and hired a development lead. Under the new lead, ARE TOO continued to work on styling, adding variables to SDK and building React components.
Building a React Component
Nandoβs Peri-Peri Chicken wanted to feature a menu item atop of their menu listing. Because the SDK intends for all code to be reused, we built a feature image React component that synced with the config and assets directory. This enabled all future clients to turn on and brand a menu feature image as well!
ARE TOOβS RESPONSIBILITIES
design
sketches and whiteboarding
customer journeys
brandable asset creation
wireframing
prototyping
interaction design
content design and ux writing
develop
Styling all elements for desktop and mobile
Committed, pushed, and merged changes to the Grubhub staging environment
Developing ReactJS component
Adding style variables to SDK components
launch and scale
Testing environments (staging, QA, and production)
Repeating the development process for each new client and developing custom work into the SDK for up-sell opportunities
Documentation
VISUAL OVERVIEW
THE OUTCOME
The Grubhub brandable online ordering SDK was a massive undertaking that started out as a new product idea. It was designed to extend merchant brands to a new channel; it has completely taken off as its own product offering since being fully built in 2018 and within its first year, has been sold to clients over a dozen times.
$250K in flat-rate revenue (sold for $20K to $40K depending on configuration)
Recurring revenue of $50 per location per month (around $10K in weekly revenue and growing)
Custom configurations and features (that are then built into the SDK to be resold)
Adoption by clients like Chase Pay, Nandoβs Peri Peri, Smoothie King, and so many more
2 new full-time hires
15+ restaurant chains in contract