This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle. “Bhaiya, 25 copies nikal do, A4, kal chahiye.”
For a print-shop owner, that message leaves several questions: colour or black and white? Single-sided or double-sided? Any binding? What time tomorrow? I built PrintBrief, a local AI assistant that turns informal customer messages into structured, editable print orders.
It extracts printing instructions, flags missing or contradictory details, and suggests clarification questions. The owner reviews the order, adds a PDF for page counting, and gets an itemized quote based on their shop’s rates.
Once confirmed, the order is saved locally with a quotation snapshot and a downloadable PDF job slip.
Who might pay for it? Small neighbourhood and campus print shops that regularly receive orders through messages. The proposed value is less manual order entry, clearer instructions, and fewer mistakes caused by guessing. That willingness to pay still needs validation with shop owners.
The demo shows customer-message extraction, missing-information prompts, manual corrections, quotation calculation, order confirmation, and job-slip download.
PrintBrief is a local-first web application designed for neighbourhood and campus print shops. It bridges the gap between chaotic customer WhatsApp/email messages (in English, Hinglish, or shorthand) and precise print production specifications—extracting requirements with a local open-weight LLM, counting PDF pages purely in the browser, calculating deterministic quotes in integer paise, and generating official printable job slips.
Print shop owners face frequent friction when receiving customer orders:
Repository: PrintBrief on GitHub PrintBrief uses:
The open-weight model performs the central task: interpreting informal customer language and converting it into structured order fields.
Application rules then check for issues such as contradictory printing instructions or pickup times without AM/PM. The owner can correct every extracted field before confirming.
Pricing is calculated in code using integer paise. For example, an 11-page document printed double-sided in three separate sets requires 18 physical sheets and 33 printed sides. Binding is charged per set, using the shop’s configured rates.
The project includes deterministic tests for validation, ambiguity handling, and quotation calculations, plus a conditional live Ollama integration check. These checks do not guarantee extraction accuracy on every possible customer message.
Local inference makes the product practical in three ways.
Customer text stays local. With Ollama running on the same computer, the extraction workflow does not need to send customer messages to a third-party AI service. Uploaded PDFs are counted in the browser and are not sent to the model.
There are no per-request cloud inference fees. Running the model locally still uses hardware and electricity, but processing another order does not create another paid API request. That gives a small business a different operating-cost model.
The model can be changed. The Ollama model is configurable, so I can experiment with other open-weight models and improve prompts for the language and shorthand used by a particular shop.
A closed API could also extract order details. The benefit of this approach is control over where inference happens, which model runs, and how the workflow behaves.
PrintBrief is a working prototype demonstrated with sample orders. It has not yet been tested by a print-shop owner, and I have not validated pricing or willingness to pay.
My next step is to test it with a local shop, measure the corrections each order needs, and learn whether it saves enough time to become part of their daily workflow.
The goal is simple: help a shop owner turn an unclear message into an order they can confidently print.