← Our work

Case study · Keychat · WhatsApp commerce

Food ordering that never leaves WhatsApp.

Keychat is our own product. We built it to give restaurants what delivery apps don't: their customers, at a fraction of the fee. We still run it, for paying merchants, every Friday night.

Visit keychat.co.za
Who it's for
Restaurants and food businesses in South Africa
Our role
Product, design, engineering and operations
Running since
2025, live with paying merchants
Team
Four engineers
The Keychat Feast website

Close to R1m in orders, one chat at a time.

~R1min orders processed
5,000orders
100k+messages handled
27businesses on the platform

The problem was never the menu.

Ask a restaurant owner what hurts and it isn't the menu or the food. It's the fee on every order, the phone at peak, and customers they can never speak to again.

Marketplaces take up to 30%

Delivery apps charge restaurants up to 30% of every order and keep the customer. The restaurant never learns who ordered, so it can't invite them back.

The phone jams at peak

Friday between six and seven, booking calls and delivery calls arrive together on the loudest shift. Someone has to stop serving to answer.

No way to reach past customers

Regulars order once and disappear into a call log. There is no list, no opt-in and no way to tell a lapsed customer about tonight's special.

“The highest peak time is a Friday night, like six to seven o'clock. If you've got somebody phoning up trying to make a booking, then somebody's trying to phone you and place a delivery… those have always been issues in the past.”
Owner, I Love MelkiesOn Keychat for about a year

Built with restaurants, not for them.

Market fit doesn't come from a brief. It comes from time with the people who use the product, then shipping, then measuring, and going round again. It's the same loop we run for clients, run here on our own product and our own money.

  1. 1Discover

    In the restaurant, not the boardroom

    We spend time with owners and staff in their restaurants, where the orders happen, and record interviews about their busiest hour. Before we built, we ran our own planning phase on the brief: features that failed the removal test were deferred, and gaps the brief missed were added.

  2. 2Ship

    Set up by hand, on purpose

    There is no self-service yet, by choice. We onboard each restaurant ourselves, from the first call to go-live: menu, payments, WhatsApp number and till integration. We print and deliver the QR table stands, train the staff who run the till, and watch the first orders closely.

  3. 3Measure

    Fit is a number, not a feeling

    Every feature answers one question: does it help prove the restaurant earns more? We separate new revenue (lapsed customers back, bigger baskets, more frequent orders) from orders that only moved off the phone. Till integrations give us the restaurant's total sales to measure against.

Everything happens in the chat.

Customers already have WhatsApp open. So ordering, booking and paying live there, and the restaurant keeps the relationship. The fee is 5% per order, between R5 and R25.

Order, book and pay in the chat

Customers browse the menu, order, book a table and pay without leaving WhatsApp. No app to install and no website to find.

A customer list the restaurant owns

Every order adds an opted-in contact. Audiences like lapsed (60 days quiet) or frequent (three orders in 30 days) drive template broadcasts.

Fewer empty tables

Reminders go out the day before, customers reconfirm in the chat, and staff mark attendance, so no-shows are counted, not guessed.

Reporting operators use

Message delivery from sent to read, week-on-week orders and payments, and a retention funnel from first contact to regular.

Under the hood.

The hard part of chat commerce isn't the chat. It's money, prices and other people's systems, for dozens of businesses at once, on a team of four. The big choices are written up as architecture decision records, so the next engineer knows why.

  • Meteor 3
  • React 19
  • TypeScript
  • MongoDB
  • Redis + BullMQ
  • Zod
  • WhatsApp Cloud API
  • Paystack · Yoco
  • Claude · Gemini
  • Kubernetes · Helm
  • Cloudflare Workers
  • Capacitor (Android)

One deployable, on purpose

A single Meteor process and a single MongoDB database, scaled up before it is split. Redis and BullMQ queues handle the work that waits: sends, reminders and retries. A second service has to earn its place. We once ran a separate machine-learning service for months, saw it barely used, and deleted it.

Conversations are code

Each restaurant's chat runs as a versioned TypeScript program written against a small kernel SDK. It replaced the graph-of-nodes workflow engine we started with. AI models (Claude and Gemini) act only through a fixed set of tools, and a customer's phone number never enters a model's context.

Every business walled off

All the restaurants share one database, so isolation can't rest on convention. A code generator wires every service, and services that act for a customer or a restaurant only ever see data narrowed to that business: reads carry the business, writes stamp it.

The server sets every price

One pricing pipeline handles the preview, the re-price after login and the final order. It reads item ids, quantities and options from the cart and looks every price up in the catalogue again. A price sent from a phone is never trusted.

Payments split at the source

Paystack split payments route the restaurant's money and Keychat's fee in the same transaction, with the processing fee shared in proportion. Yoco is supported too.

Plugs into what restaurants already run

Point-of-sale (Pilot) and online stores (Shopify, Ecwid) all plug into one registry, so connecting or disconnecting works the same way for each. Catalogues sync field by field, and items that can't be filed land in a staging category for staff to sort.

Four engineers, the pace of a bigger team.

AI coding agents work alongside our engineers, several at once, each in its own copy of the code. The engineers decide what to build and check that it's right. Four people own Keychat from the user's problem to the 3am integration failure.

The repo is written for people and agents alike: a domain glossary, 16 architecture decision records, acceptance scenarios in controlled English, and issues written as specs an agent can pick up. The build rejects any change that breaks a scenario or crosses a layer boundary, whoever wrote it.

  1. 1ChecksTypes, lint, layer boundaries, spec drift
  2. 2BuildOne production bundle
  3. 3Back upThe database, before every deploy
  4. 4DeployTo Kubernetes, with Helm
  5. 5Roll backOne step away if it goes wrong
3,165commits since March 2025
294releases in six months since v1.0
~1,250acceptance scenarios
543commits in August 2026 alone

Busy enough to buy a second oven.

“With our bookings now and the online ordering system, we're looking at a second pizza oven. Full restaurant and online orders on a Friday, we always look at that as the benchmark.”
Owner, I Love MelkiesPizza restaurant
“We have seen a massive boost in turnover when we started using Keychat. It has been incredible!”
Chanelle KleynhansManager, La Cuccina

Running our own product taught us what a client build doesn't: onboarding at scale, billing edge cases, and what a support message looks like when an owner writes it mid-service. It's why every engagement we take on starts with the users and ends with the numbers.

More of our work.

Have a product that needs to work on a Friday night?

Thirty minutes with Regardt or Dean. You'll leave with the user problem to solve first, a first release scope and an initial budget range.

Book a free call