I joined Wi5 in 2018, and worked as Tech Lead working predominately on their architecture, AWS infrastructure, and building their Point-of-Sale integrations and payment processing systems. Wi5 was a POS integrated Order & Pay system for the hospitality industry. Wi5 has since pivotted to focus on payment processing and renamed to “Onvi”.

QR-Code Ordering Platform

Wi5 began as an initiative to build a Single-Page-App with Order & Pay functionality based on captive-portal WiFi technology. Unfortunately, the technology did not perform well as platform support across different devices was poor.

I spearheaded the pivot to a QR-code based entrypoint. This was a relatively novel idea at the time (2018) and was originally met with skepticism by the team. However, it was a massive success and has now become the de-facto standard for ordering in the hospitality industry.

Backend Decisions

Our team had originally built a number of backend prototypes in NodeJS. The results were not particularly impressive and we were struggling to maintain the codebase, even in our early stages. The NodeJS ecosystem we felt was immature, and the choice of frameworks and libraries was leading to the team spending too much time in fruitless debate.

When our lead NodeJS engineer was asked to leave, we faced a difficult decision. Should we continue to build on the NodeJS backend?

I had recently worked at Quiqup and Grouper where I’d seen firsthand the speed and ease an early stage startup could build and iterate on a product using Rails. I proposed to leadership that I build a prototype. I was able to deliver a working prototype for both our Point-Of-Sale integrations and our QR-code ordering platform within 10 days.

The team agreed that Rails, coupled with the fantastic ActiveAdmin library, offered the best go to market solution.

You can read more about my reasoning here: Why I Believe Rails is Still Relevant in 2019.

Point-Of-Sale Integration

After a number of prototypes and iterations, we locked in on a solution and I built the original Point-Of-Sale integration with Lightspeed POS. I then built an additional integration with NCR POS.

Eventually I would build out a Ruby engineering team to build our additional Point-Of-Sale integrations based on my original plugin architecture. We eventually integrated with 5 major POS systems, and would eventually even build our own light-weight POS!

Our Infrastructure and Architecture

I decided we had no need for Kubernetes at this stage of the product. I built a GitOps system that triggered a Docker build, and used Terraform to declaritively define our AWS infrastructure.

I chose the ECS Fargate service as our container runtime. This allowed us to deploy our application to AWS quickly and easily, and removed the need for us to manage any underlying infrastructure.

At our small size, I feel this was the perfect trade-off between complexity and cost.

I architected the Wi5 system to operate as 2 separate loosely coupled services.

• Houston

  The first service was nicknamed “Houston” and was essentially a Rails “monolith”. This service was our admin portal, our customer onboarding portal, and our Point-Of-Sale integration service. The Houston service ran regular background jobs to synchronize data between our various systems, and import our customers’ menus into our system.

  Houston has able to operate independently of the Order API, and simply provided a series of configuration and menu artefacts to the other system via a static S3 storage bucket.

• Order API

  The second was our runtime order processing service. This was what our end customer (and our customer apps) would interact with to place orders and pay for them. This was kept incredibly lightweight, with very little code and few dependencies.

This architecture was great, because it allowed us to iterate quickly on Houston without having to ever worry about “bringing down the system”. Because the Order API had no runtime dependency on Houston, even when our Houston service was undergoing rapid change, the Order API could continue to operate normally.

In addition, because the published artefact was just JSON, we could onboard new customers rapidly by simply deploying dummy JSON artefacts to our S3 bucket and allow customers to test the system before we had built the full integration.

Our First Customer

Before we had built our payment processing system, we began onboarding our first customer, Bounce, a ping pong bar in London with multiple locations.

Point-Of-Sale systems are often abused by staff and frequently include duplicate items, spelling mistakes, and many other issues. This meant we had to design an “enrichment layer” to our Houston service to allow our customers to override aspects of their POS menu for public display.

Payment Processing

I single-handedly built our original payment processing using a modular architecture that allowed us to easily add new payment providers.

I integrated with both the Sage Pay and Adyen payment providers. This included multi-tenant Google Pay and Apple Pay support, and 3DS-enabled card payments.

Rapidly Scaling Up

With our proof-of-concept complete, and our product processing orders successfully in the real world, we began to rapidly scale customer acquisition and with that, our own engineering team. We opened a number of new positions and grew the team to 16.

As I filled these positions, I turned my focus to the new technical bottleneck of our system: customer onboarding.

Customer Onboarding

I began to address this bottleneck by buliding a modular onboarding system that allowed us to programmatically generate multi-step VueJS forms with full validation and error handling.

We could design and deploy a new multi-page wizard in minutes, and we could even generate the JSON artefacts automatically from a simple YAML file.

This allowed us to rapidly iterate on our onboarding process and again, we decoupled the onboarding process using static JSON artefacts. Every onboarding wizard produced a structured JSON artefact that could be imported into our system, backed-up, versioned, and hot-swapped in a matter of seconds.

This meant the team could rapidly remove repetitive Know-Your-Customer (KYC) questions, POS integration questions, menu customizations, and many other steps and replace them with automated onboarding flows that fed directly into our Houston service.

In less than one year, our team would go on to onboard thousands of locations, including well-known brands such as: Pret a Manger, Patisserie Valerie, Pizza Pilgrims, Goose Island, Crepeaffaire, Pho, Bounce, Puttshack, Market Halls, Big Easy BBQ Crabshack, ETM, All Stars Lanes, Barrio, Laney, UCL, Ole & Stten, Davy’s Wine Merchants, Box Park, Chik’n, Dirty Bones, The New World Trading Company, Rosa’s Thai Cafe, Drake & Morgan, Upham Pub Company, and The Corbet Arms.