BatchBrief: Less Scrolling, More Baking with Local AI

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

BatchBrief turns messy customer conversations into reviewed bakery orders and daily preparation lists.

It’s built for home bakers who take custom orders through messages. The details arrive in pieces: a quantity, a flavor, a pickup time—and then a correction several messages later.

Here’s a synthetic example used during testing:

“I need 12 lemon cupcakes for pickup tomorrow at 4 pm.”

“Actually, make that 18.”

“Please change pickup to 5:30 pm.”

BatchBrief reads the conversation and creates an editable order card. It captures items, quantities, flavors, decorations, fulfillment details, and questions that still need answers.

The baker reviews the original messages alongside the extracted details. Only confirmed orders enter the preparation list. Different decorations, dietary requests, and item notes remain separate when quantities are grouped.

The workflow is:

Paste → review → confirm → prepare.

Bakers can also save incomplete drafts, edit orders, mark them completed, and export or print their daily prep list.

My commercial hypothesis is that home bakers could pay for installation, setup around their menu, and support. Willingness to pay still needs validation with real users.

Demo

BatchBrief runs locally. After installing Node.js 22.13 or newer and Ollama, download the model:

ollama pull qwen3:8b

Then, from the project folder:

npm start

Open http://127.0.0.1:4317.

The app includes clearly labeled example conversations. These populate the message box; extracting them still calls the actual local model.

This first version accepts pasted text from one customer conversation at a time. It does not connect directly to WhatsApp or process voice notes.

Code

godlykmathews / batchbrief-hf26

BatchBrief

BatchBrief turns one customer's bakery order conversation into a reviewable order card and a daily prep list. A local open-weight model reads the pasted text; the baker checks the details and decides when an order is confirmed.

This is a local, single-user prototype. There is no hosted demo, customer trial, paid user, or established accuracy benchmark yet.

What it does

• Extracts items, quantities, flavors, decoration requests, pickup or delivery details, and unanswered questions from pasted text.
• Keeps the original conversation and supporting quotes alongside the draft.
• Lets you correct details, save incomplete drafts, confirm reviewed orders, and mark finished orders completed.
• Builds the selected day's prep list from confirmed orders. Different flavors, decorations, units, and dietary notes remain separate.
• Exports CSV and printable views for the baker's workflow.

The MVP accepts text from one customer conversation at a time. It does not connect to WhatsApp, ingest voice notes…

View on GitHub

The application code is MIT licensed. Model weights are downloaded separately through Ollama.

The repository includes the application, setup instructions, automated tests, synthetic model-evaluation results, and a proposed first-user pilot.

How I Built It

The core is Qwen3-8B, an Apache-2.0-licensed open-weight model running locally through Ollama.

The surrounding application is deliberately small:

• Vanilla JavaScript, HTML, and CSS for the interface.
• Node.js for the local server.
• SQLite for saved orders and their original conversations.
• Ollama structured outputs for extraction into a defined JSON schema.

The model interprets the conversation. Ordinary application code validates fields, controls confirmation, stores records, and calculates preparation totals.

A valid JSON response does not guarantee a correct order. An early test demonstrated that clearly: the model put an unnamed customer’s opening sentence into the name field. That led to tighter extraction instructions and a conservative validation check.

BatchBrief also checks that supporting quotations occur in the source. Those checks help, but a quotation can still be attached to the wrong item. The baker’s review remains essential.

Verification included:

• 13 deterministic tests covering storage, validation, local-model restrictions, preparation grouping, and CSV handling.
• 9 applicable browser scenarios across desktop and mobile emulation.
• 5 synthetic cases using the actual local model, covering corrections, missing details, dietary requests, and pasted instructions.

The five real-model cases passed their assertions after the fixes. They are regression examples, not an accuracy benchmark or a customer trial.

A useful community reference was Michael-Maurice’s article, Schema-Valid Isn’t Correct. Its discussion of evidence and validation informed the review workflow. Read the full discussion.

I used Codex to assist with implementation, testing, and this write-up.

Why Does Open Innovation Matter?

Open weights make local inference practical for this project. Customer messages can be processed without sending them to a hosted model API.

That matters when conversations contain names, phone numbers, addresses, and personal requests. Saved records stay in the application’s local SQLite database, although exports and operating-system backups still need ordinary care.

Owning the inference setup also changes the business model. Repeated extraction does not create a per-request hosted-model bill. Hardware, electricity, installation, and support still have costs, but usage is not tied to an API provider’s message pricing.

The prompts and validation logic are inspectable. Another installed local model can be evaluated without rebuilding the order-management workflow.

For BatchBrief, the practical advantages are local processing, adjustable behavior, and control over inference costs. The open model performs the central task: turning an unstructured conversation into something a baker can review and use.