Employer platform · 2025

Nomly — AI assistant for restaurant operators (2025 foundation)

Problem: Operators' answers were scattered across documents, email and the point-of-sale system.
My role: Full-stack and AI engineer on the 2025 foundation of Nomly, Crave's assistant for restaurant operators.
What changed: Document and email retrieval with pgvector, LangChain and LangGraph agent workflows, voice, multi-tenant organizations and billing.
What was verified: Retrieval stays limited to documents, PDFs and email; point-of-sale context enters through a separate integration. Product has evolved since.

Nomly is Crave's AI assistant for restaurant operators. This case covers the 2025 foundation I helped build: chat grounded in the company's documents, PDFs, and email, with point-of-sale context incorporated through a separate integration layer. Built on a real retrieval pipeline and agentic workflows; shown with sanitized diagrams.

01 / 04 · System overview

How Nomly uses information

Nomly assistant connected to team documents and email, with document search and point-of-sale integration shown separately — The original Nomly foundation I helped build at Crave. Document search and point-of-sale integrations are separate paths; this is not a view of every current product capability.

01 Scope

The product context behind the work.

Problem

Operational knowledge was scattered across documents, email threads, and the point-of-sale system. Answering everyday questions meant digging through files and systems by hand, and the same questions came up again and again across locations.

My contribution

Built the retrieval pipeline: ingest and normalize documents, PDFs, and emails into chunked, embedded, searchable content (Supabase / pgvector)
Implemented agentic chat workflows with LangChain + LangGraph so answers stay grounded in the company's own data, with chat sessions and auto-generated titles
Connected point-of-sale context through an integration layer so the copilot could be designed around operational data, not only static documents
Delivered multi-tenant organizations, locations, users, billing, insights, and a voice interface (speech-to-text / text-to-speech)

02 Approach

Important engineering decisions.

Nomly is Crave's personal AI assistant for restaurant operators. The product has evolved since the 2025 foundation described here; current capabilities are described on nomly.ai. The voice channel later became CaterVox, Crave's AI catering manager, which I have also contributed to. My contribution is bounded to the surfaces listed under "My contribution"; Nomly is Crave's product.

The 2025 foundation focused on an AI operations copilot for restaurant operations. The operating idea was simple: most operational knowledge already exists - in documents, email threads, and the point-of-sale system - it's just hard to reach. So the copilot was built around getting trustworthy answers out of the company's own data, not around a generic chatbot.

The foundation is the retrieval layer. Documents, PDFs, and emails are ingested, normalized, chunked, embedded, and stored for search (Supabase / pgvector). On top of that sits an agentic workflow built with LangChain and LangGraph, so a question is answered through grounded retrieval and controlled steps rather than a single open-ended prompt. Chat sessions are saved and auto-titled so the experience feels like a real product.

A key design thread was the point-of-sale integration layer. The goal was to let operational data sit beside static knowledge sources while keeping private customer and integration details out of the public case study.

Around the core sit the things that make it operational rather than a demo: multi-tenant organizations and locations, user management, billing, insights, and a voice interface for speech-to-text and text-to-speech.

03 Evidence

How it works.

02 / 04 · Product journey

From a question to an answer

Question moving through source search and approved context to an answer with sources — The assistant finds source material and prepares an answer. Document search and point-of-sale context remain separate inputs.

03 / 04 · System boundary

Making documents searchable

Documents and email cleaned, split into passages, made searchable, and stored for answers with sources — Documents, PDFs, and email are prepared for search. Point-of-sale records stay out of the document search index and embeddings.

04 / 04 · Delivery / verification

The tools around the assistant

Business accounts, locations, users, saved conversations, billing, insights, and voice around the assistant — Business accounts, locations, users, saved conversations, billing, insights, and voice support the assistant. This case covers the foundation I helped build.

04 Delivered & verified

What the public proof supports.

Delivered scope

Grounding

Retrieval-backed (RAG) answers over the company's documents, PDFs, and email, with point-of-sale context incorporated through a separate integration layer.

Reach

One copilot across documents, email, and point-of-sale, for a multi-location, multi-tenant business

Scope

Ingestion pipeline, agentic backend, point-of-sale integration layer, voice, multi-tenant orgs, and billing

Stack

Next.jsTypeScriptSupabase / Postgres (pgvector)LangChainLangGraphOpenAIVercel AI SDKExpressStripe

Reflections

The hard part wasn't the model - it was the data layer: clean ingestion, chunking, metadata, and grounding so answers stayed trustworthy.
The point-of-sale path was framed as an integration layer so operational data could sit beside static documents without exposing client or vendor identity.

Next step

Have a similar project?

If this looks close to the product work you need, book a short call and I will help scope the next step clearly.

Book an intro call Email me