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!