<aside> 🪄 “If I didn’t have Replay, it would have taken me several days or even weeks getting the debugger to run properly in all the dynamically loaded scripts, which is not easy. With Replay it took me half a day to figure it out and get a fix ready.” - Simeon Cheeseman, Principal Engineer

</aside>

Summary

TableCheck Challenges

• Expanding into numerous markets globally and launching new UIs per market
• Managing QA/Support issues and inter-team communication at scale across multiple front ends, a monolith single page app, and many languages
• Building new landing pages and moving tech stacks resulting in hard-to-reproduce bugs

How Replay helps

• Significant time savings between QA and Engineering, resulting in a scalable approach to supporting new markets and features
• Greater developer velocity via improved code reviews and a greater understanding of routing and core issues across teams and front ends
• A tools usable by engineers with varying tech stacks that can move from project to project with little context

What is TableCheck?

TableCheck has built a global platform to empower restaurants to reach their full potential and own their whole guest experience. TableCheck helps restaurants reduce reliance on paid booking channels by directly converting first-time diners into repeat guests⁠—and repeat guests into loyal fans. The company has become the standard solution for restaurants and hospitality businesses around the world to drive guest loyalty and revenue.

The company started in Japan, assisting large hotel chains and top end restaurants manage reservations by allowing optimal use of available tables and avoiding double booking. TableCheck’s business model is all about supporting restaurants to give the best experience to their diners.

Managing across markets, front ends and tech stacks

Providing a custom experience to thousands of hospitality customers across the world requires a mix of micro front ends and various technologies. Ensuring that teams with different tech stacks could work together became a challenge as the business scaled.

The TableCheck engineering team is evenly split between front end and back end, with both teams using a variety of frameworks, architectural approaches, and languages. These include React, Ember, single-page applications (SPAs), micro front ends, server-side rendered applications (SSRs), Elixir, and Ruby. Developers also created their own systems, which provided more control but were more difficult to maintain.

“We also created a fork of the Create React App system,” said Simeon Cheeseman, Principal Front End Developer. Simeon has worked on a variety of projects at TableCheck and worked on most of the code across the front end. “When it's your own system, you can make a lot of your own choices without being shackled by the open source maintainers choices. The downside of this is, if you write it you’re the one who maintains it.”

Different teams across the core user flows like Diners and Restaurants used different approaches, resulting in various versions of the user-facing front ends as they launched new features per market. This made communication between developers and user-facing teams like Support more challenging when reproducing and debugging issues.

Building shared understanding with Replay