Leon Restaurants

In an unusual twist, Leon asked us to take on the support and management of their incumbent site whilst working on their new one.

That site was a WordPress build conceived, we suspected, when it was a much smaller restaurant chain at fewer locations. Over time, it had grown to do gallant service, catering (pun intended) for over 40 sites in 6 international territories. But in the code, the growing pains were plain to see.

But why take this on whilst concurrently working on the replacement? Well, we gained valuable knowledge and saw immediate benefits.

• It gave us several months of first-hand insight into how Leon worked across departments, the creation of its menus, content, and how marketing material got approved within the company.
• Beyond the architectural and maintenance challenges, we gained direct experience where the pain points lay from a content creation and management perspective.
• And this information was invaluable when it came to planning and building a new robust platform that would stand up to their 5-year-plan and beyond.

So, whilst partnering creative agency 48.1 conducted their branding, strategy and UI/UX work, we set about planning how we’d make the lives of Leon’s marketing team considerably easier.

There were 5 things we felt were absolutely critical.

1. Data gets entered once

And not just once in the CMS, once in the whole of Leon. If data was maintained elsewhere, then we would integrate it. If content was authored elsewhere, we would import it. And if our content was needed elsewhere, access we would grant it.

2. Architecture is as future proofed as possible

Leon was expanding in many directions. More restaurants, new territories, innovative food items, books, homewares, groceries, and now storytelling. Simply put, what was required for launch would need to adapt quickly and continue to do so for a company likely to be looking different in 5 years’ time.

3. UI is data-driven

With so many stakeholders rooting for an ever-nearing deadline, all parties had to be clear on how site data was interrelated. For example, if a slideshow of vegan rice boxes were to appear on a page, how would it be generated? Would it update automatically or manually? Could it be overridden and, if so, how? What information about each rice box would need to be shown? To achieve this, we insisted that the data structure be agreed before the UI was started. As a result, designers understood what needed to be included, developers knew what had to be built, and everyone understood the implications of quickly adding something to the UI design.

4. Don’t back Leon into a corner.

Websites date as the technology behind them dates. We wanted to make it easy to swap out the CMS for another, or to deploy the infrastructure to another device or platform without a complete rebuild of the site. We wanted to be able to add services as they came on board. We wanted a distributed and component-based platform, an ecosystem for Leon that would match the diversity of their growing brand and evolve with them.

5. Empower Leon with flexible content management

We really didn’t want Leon to have to come to us every time they needed a new page. With the knowledge of the data structure and a UI ‘style guide’ we pushed from the outset that we’d be taking a modular approach to the build. So, if they had a new campaign with new content, aimed to attract different traffic, then the page could be built in a way which was comprised of a subset of modules and published without any input from us. For us, this is what a content management system is for.

React is great for one-page applications. One-page applications are, however, terrible for SEO, so we needed to work around that by rendering the React on the server first. We did a quick audit of server side React frameworks and settled on Next.js. To make things snappier still, we also opted to use Next.js to statically generate the production site; that is to write the whole site to static html pages, as if the site had been manually written out by hand.

Beyond those SEO advantages, that decision brought 3 additional benefits:

• Loading a page requires no database connection, so it’s really fast to respond, especially when the site is under heavy load. We’d learnt first-hand how spiky the Leon traffic could be: a Radio 2 appearance by Leon founder John Vincent sent the traffic up 10-fold for 2 subsequent hours.
• Once the initial page load has happened, the React application takes over as a single-page app, giving users the snappiness they expect in page and state transitions.
• The production site would have no runtime dependency on the CMS, so should the CMS fail for any reason the site would not go down, as the two were not connected. Given we were supporting the site after go live, adding this level of redundancy was really useful, and negated the need for Sanity’s enterprise support costs.

One hefty CMS implementation later, we had built a data import tool for all Leon’s menu items, integrated opening times direct from the till system, used TFL and Google Maps APIs to deliver integrated location services, and delivered a service that pushed data to their CRM and pulled from their podcast platform. Oh, and we built 44 modules for them to arrange their content.