Table for One

Why I built it

On Saturdays, my son and I visit a nearby children’s museum where we have a membership. Afterward, we get two cheeseburgers from STK. It’s a small routine I wanted to make easier.

Each order meant another call to the restaurant’s voice AI and another round of the same questions. Explaining two cheeseburgers took too long. I wanted to tap our usual order or say what we wanted, review it once, and let my own assistant handle the call.

That became Table for One, a private web app for my takeout orders. I started with our STK order, then expanded it to saved restaurants and different meals. The new build is ready for further testing; restaurant calling remains disabled.

The experience

I can speak or type an order, or load a saved favorite. The app turns the request into editable fields for the exact restaurant location, each item and quantity, special requests, and pickup time. Missing or ambiguous details need an answer before I can continue.

I choose a card nickname or payment at pickup, add a tip, and set a maximum total. A separate review screen shows the whole order before submission. Speaking or filling in a draft cannot start a call. During a call, the restaurant must confirm the items, price, and pickup time within those limits.

If a modification is refused or the conversation needs my help, the assistant can ask me to join the same call. The app tracks the confirmed total, ready time, and outcome. Payment at pickup stays marked as due, and an unclear outcome stays unresolved.

How it works

View the full-size workflow map

1. 01
   Turn words into a draft

   OpenAI transcribes spoken input and extracts order fields from voice or text. A saved favorite can fill the same draft.

2. 02
   Review and approve

   I check the location, food, quantities, pickup time, payment preference, tip, and spending limit before submitting.

3. 03
   Call the restaurant

   Twilio carries the phone audio. An on-demand EC2 worker connects the call to OpenAI Realtime for the conversation.

4. 04
   Resolve payment

   Prepaid orders need my private participation. Payment at pickup requires both my choice and the restaurant’s acceptance.

5. 05
   Confirm or ask for help

   The app records the confirmed total, ready time, and outcome. If the call needs me, I can join the existing conversation.

V8 is built but not deployed. Restaurant calling is disabled, and automatic real-card payment is not implemented.

The website and order records stay available while the voice worker is off. Call attempts have a saved identity, so a lost response does not justify dialing again. Editing a saved restaurant cannot change the destination of an order already submitted.

The diagram uses n8n-inspired nodes and connections to show the process. The app runs on custom TypeScript code and AWS services.

Stack and choices

Order and reviewReact PWA · TypeScript · Vite · Fastify

Keep the editable draft, review, history, and takeover controls together.

Voice and text inputOpenAI transcription · structured outputs

Turn a short request into fields that I can check before ordering.

Phone conversationTwilio · OpenAI Realtime · WebSockets

Connect restaurant audio with the assistant and support human takeover.

App and order recordsAPI Gateway · Lambda · DynamoDB · S3/CloudFront

Serve the app, handle requests, and save order and call records.

Voice workerEC2 · AWS CDK

Start the persistent connection worker when a call needs it.

I chose AWS because I wanted to become more familiar with its tools by building something I’d use myself. It gave me a reason to learn how hosting, storage, permissions, and background work fit together.

S3 and CloudFront serve the website. API Gateway and Lambda handle requests, and DynamoDB saves orders and preferences. EC2 runs the ongoing audio connection only when a call needs it. Secrets Manager holds provider credentials, while CloudWatch and SNS support operational logs and email alerts. With only a few calls a month, I can stop the voice worker between orders, though storage and other services still have costs.

Decisions and design lessons

A favorite still needs review. Saved items remove repetition, but the restaurant, quantities, pickup time, and spending limit remain visible. The assistant cannot quietly swap an item or accept a higher total.

An unclear outcome needs checking. A dropped connection does not prove that an order failed. The app preserves the submitted request for recovery and gives me a way to take over the conversation.

Payment needs its own boundary. Twilio provides the phone connection; the restaurant handles payment. Saved card labels contain the nickname, brand, and last four digits, without full card details. Real card payment needs my private participation, and automatic card entry is not implemented. An order accepted for payment at pickup still has money due.

Current state and next step

As of October 9, 2026, the v8 implementation passes 379 automated tests and 19 local simulated-call scenarios. It supports saved restaurants and favorites, voice or text drafts, multiple items, requested pickup times, review, and takeover controls. These checks use synthetic data and do not prove real restaurant or iPhone behavior.

The older STK v7 release is deployed on AWS with calling disabled. The new v8 build has not been deployed or evaluated in new real-model or audio calls. Next are model-conversation evaluation, a controlled call with a consenting test recipient, and physical iPhone dictation checks before enabling restaurant calls. Real-card automation remains outside this release.