Ten years of WhatsApp chats, turned into structured data.

For nearly a decade, Dough Man Foods took orders the way most Ghanaian small businesses do — through free-form WhatsApp messages. No form, no fields, no consistency.

That history was a goldmine of customer behaviour sitting completely locked in unstructured chat text. I built a two-stage parsing pipeline — regex first, LLM second — to convert a decade of raw WhatsApp order history into clean, structured records in Supabase.

A decade of customer orders lived only as WhatsApp chat history — thousands of messages like "2 boxes chocolate glazed for Saturday, deliver to East Legon" mixed in with casual conversation, price questions, and complaints. None of it was queryable.

There was no way to answer basic business questions — which flavours sell best in which month, which areas order most, what the real repeat-customer rate is — without manually reading years of chat logs.

Free-form text like this doesn't parse cleanly with one method alone. Pure regex breaks the moment a customer phrases an order slightly differently — "2 choc doughnuts" vs. "chocolate x2" vs. "the usual, 2 pieces." Pure LLM parsing on ten years of messages is slow and expensive if it's doing all the work from scratch.

The data existed; it just wasn't usable. Reading a sample of the message history made the shape of the problem obvious — most orders followed a handful of predictable patterns, but a meaningful minority were conversational, ambiguous, or mixed multiple items into one message. No single parsing method was going to handle both cleanly.

So I designed a two-stage pipeline instead:

• Regex pass — catches the high-confidence, clearly structured patterns first (quantities, common flavour names, dates) cheaply and instantly, handling the bulk of well-formed messages without needing a model call at all.
• LLM pass — takes everything the regex pass couldn't confidently resolve — ambiguous phrasing, slang, multi-item orders written conversationally — and interprets it with actual language understanding, extracting structured fields.

This kept cost and speed reasonable while still achieving high accuracy on the messy, real-world language customers actually use — the same way a bank flags only unusual transactions for manual review instead of reviewing every single one.

Raw WhatsApp order history is pulled from chat exports. A Python regex parser runs the first-pass extraction of clearly structured order patterns. Anything it can't confidently resolve goes to the LLM parser for a second pass, normalising the result into consistent fields — item, quantity, date, location, customer. Supabase stores the cleaned, structured order history as queryable records.

An output-generation layer then produces customer-facing delivery fee materials in CSV, PDF and HTML from the same structured data — so the same pipeline that cleaned historical orders also now powers current customer communication.

The LLM only sees what the regex pass couldn't resolve — the ambiguous, conversational, slang-heavy minority of messages. That's a deliberate division of labour: language understanding where it's actually needed, and nowhere else.

The decision to split parsing into two stages, rather than reach for an LLM on every message, was the core engineering call — it's what kept the pipeline affordable and fast enough to run against a decade of history rather than a sample of it.

It's tempting to just throw an LLM at everything. The real discipline was figuring out how much of the problem didn't need one, and trusting the cheap, deterministic method to carry the bulk of the load.

A decade of previously unusable chat history became a structured, queryable dataset — turning years of "we probably sell more chocolate glazed around holidays" gut-feel into data Dough Man can actually check.

The two-stage design — cheap deterministic method first, expensive intelligent method only for what's left — is a pattern worth reusing anywhere messy real-world data meets AI.

The historical data-cleaning work and the live customer-facing tooling now share one system instead of being two separate efforts. The same output-generation layer is built to extend to new document formats as the business needs them, without touching the parsing pipeline underneath.