PrintBrief: Local AI Turns Messy Messages Into Print Orders

Starting With a Real Pain Point

"Bhaiya, 25 copies nikal do, A4, kal chahiye." For a print shop owner, this typical Hindi-English mixed message means at least four unconfirmed variables: color or black-and-white? Single-sided or double-sided? Binding or not? What time tomorrow for pickup?

PrintBrief, submitted by developer SaifuddinM23 for the Hacktoberfest open-source AI challenge, targets exactly this scenario—using a locally running open-source model to parse informal customer messages into structured print orders. The project is open-sourced on GitHub, with a complete front-end and back-end implementation plus a demo video.

What PrintBrief Actually Does

The core workflow of PrintBrief breaks down into four steps:

1. Message parsing: Accepts customer text sent via WhatsApp or email (supporting English, Hinglish, and shorthand), with a local LLM extracting print parameters.
2. Missing and contradiction detection: Application-layer rules check for omissions—for example, mentioning "tomorrow" without specifying morning or afternoon, or containing conflicting instructions. The system generates suggested clarifying questions.
3. Human review and quoting: The shop owner can correct extracted fields one by one, upload a PDF to have page count tallied locally in the browser, and generate an itemized quote based on the shop's configured rates.
4. Order confirmation and archiving: Confirmed orders are saved in local IndexedDB with a quote snapshot and a downloadable job sheet PDF.

The value proposition here is clear: reduce manual entry and cut down on print errors caused by guessing specifications. Of course, as the author himself admits, whether shop owners would actually pay for this remains unverified.

Tech Stack: A Restrained, Local-First Design

PrintBrief's technical choices involve several noteworthy trade-offs:

• React + Vite for the front end, Node.js + Express for the local back end.
• Gemma 3 4B via Ollama for local inference, handling the core semantic extraction task.
• Zod for validating and normalizing model output, preventing the LLM from returning unusable structures.
• pdf-lib for in-browser PDF page counting and job sheet generation—the file itself never passes through the model.
• IndexedDB for local order history and quote snapshot storage.

The design logic here is consistent: customer messages stay on the local machine, PDFs never leave the browser, and model output passes schema validation before entering business logic. The model is configurable, meaning shop owners can swap models or adjust prompts to match local language habits and shorthand conventions.

Ollama is an open-source local large model runtime framework that supports downloading and running quantized open-weight models on ordinary personal computers (including consumer GPUs or environments without a discrete GPU). It packages model loading, inference scheduling, and API serving into a single command-line tool, exposing an HTTP interface similar to OpenAI's, so applications only need to point requests at localhost to complete inference. Compared to calling cloud APIs directly, Ollama keeps model weights on the local disk and runs inference in local memory—but the trade-off is that inference speed depends on local hardware, and model capability is typically weaker than same-generation closed-source large models. For text extraction scenarios like PrintBrief with a single task and short inputs, a 4B-scale quantized model is already sufficient.

Zod is a commonly used runtime schema validation library in the TypeScript ecosystem. Unlike type checking that exists only at compile time, Zod validates data structures and types field by field at runtime, providing specific paths and reasons when validation fails. LLM output is essentially free text—even when asked to return JSON, it may have missing fields, type errors, or extra nesting. Defining the expected order structure with Zod and parsing against it separates "what the model said" from "what the business logic accepts": non-compliant output is intercepted at the validation layer or triggers a retry, rather than contaminating downstream quote calculations. This schema-first approach is a common engineering technique for constraining LLM structured output.

pdf-lib is a pure JavaScript PDF reading and writing library that can create, modify, and merge PDF documents in browser or Node environments, reading metadata like page count without uploading files to a server. PrintBrief uses it to count pages and generate job sheets in the browser, meaning PDF byte streams always stay in the user's device memory—never passing through the local model nor sent to external services. This "files never leave the browser" pattern aligns with local inference in terms of privacy goals, and also avoids the latency and bandwidth overhead of uploading large files.

Why Pricing Deserves Its Own Section

The pitfalls in print quoting often hide in the difference between "pages" and "sheets." PrintBrief's pricing logic uses integer paise to avoid floating-point errors. The author gives a concrete example: an 11-page document, double-sided, in three sets, requires 18 physical sheets and 33 printed sides, with binding charged per set.

This deterministic calculation, combined with unit tests for validation, ambiguity handling, and quote logic, is the key to whether a small tool like this can truly ship. The model handles language understanding, the code handles the money—the boundary of responsibility is drawn clearly.

Paise is the subunit of the Indian rupee, with 1 rupee equal to 100 paise—similar to how "fen" relates to the Chinese yuan. Using integer paise rather than floating point to represent amounts is meant to avoid rounding errors in binary floating-point accumulation and multiplication/division of currency—for example, 0.1 + 0.2 in floating-point arithmetic does not exactly equal 0.3, and in quoting scenarios involving unit price multiplied by quantity, then adding binding and set fees, errors compound layer by layer. Operating with integers in the smallest currency unit and dividing by 100 only at the display layer is standard practice in financial and pricing systems, and explains why PrintBrief's quote logic is meticulous down to the last paise.

Three Reasons for Local Inference

The author gives three arguments for "why use a local open-source model," each worth examining:

Data never leaves the machine. Ollama runs on the same computer as the business, so customer messages need not be sent to a third-party AI service. For small shops handling customer orders, this is an easily overlooked but real trust factor.

No per-call cloud inference costs. Local running still consumes hardware and electricity, but processing one more order doesn't incur another API fee. For shops handling dozens to hundreds of messages per day, the cost model is entirely different.

The model is swappable. Ollama models are configurable, so the author can experiment with other open-weight models and optimize prompts for specific shops' language habits.

The author also acknowledges that closed-source APIs could equally handle the extraction task; the core advantage of the local approach lies in control over where inference happens, which model to use, and how the workflow behaves.

Current State and the Real Next Step

PrintBrief is currently a runnable prototype demonstrated with sample orders. The author explicitly lists what's unfinished: it hasn't been tested by real print shop owners, and neither pricing nor willingness to pay has been validated.

The next step is to have local shops try it out and measure how many manual corrections each order requires, and whether the time saved is enough to make it part of the daily workflow. This attitude is rare among open-source projects—many submissions stop at the demo stage, but PrintBrief at least puts "validation" on the roadmap.

For those interested in AI application deployment, the lesson from this project isn't how powerful the model is, but rather the pragmatic combination it demonstrates: a small local model for semantic understanding, deterministic code for business calculations, and human review as a fallback. Each plays its part—closer to the real workflow of small merchants than letting a large model handle everything.