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

What I Built

Picture a one-person online shop selling handmade ceramics. The owner makes the mugs, photographs them, packs them... and every evening answers the same emails: "my mug arrived cracked", "my parcel is late", "can I get a refund?". She already knows the answers. She just has to write them again, consistently, every single time.

Little Kiln Support Copilot drafts those replies for her. You paste a customer message; it finds how you solved similar cases before and writes a draft that follows your own policies. You review it and send it.

Who would pay: solo makers and small shops on Etsy, Shopify or their own site, for whom support eats hours but a full helpdesk subscription is overkill. Because everything runs on open models on the owner's laptop, there is no per-message AI bill, so a flat few euros a month (or a one-time setup fee) would be a sustainable price.

Demo

Three real runs from the command line, for a sample shop called "Little Kiln Ceramics".

A broken vase. The customer asks for their money back; the copilot recognizes a damaged item and applies the shop's damaged-item policy: free replacement within 2 days, no need to return the broken piece, a photo of the damage.

A late parcel. It promises to check the tracking and offers the 10% discount code (SORRY10) the shop used in a similar case. Notice the "In the past, we have offered..." wording: a small model sometimes leaks internal phrasing, which is exactly why a human reviews every draft.

A question nobody asked before. No past case is similar enough, so instead of inventing an answer, the draft says the owner will check.

Code

How I Built It

The copilot is a small retrieval-augmented generation (RAG) pipeline in Python, built around two open-weight Google models running locally with Ollama:

1. Past cases become vectors. Each past case (customer message + how it was resolved) is embedded with EmbeddingGemma (300M parameters, 768-dimensional vectors) and stored in Postgres with pgvector on the Tiger Cloud free plan.
2. Retrieve. A new message is embedded the same way, and a single SQL query ranks past cases by cosine similarity (<=>) and keeps only those above a threshold.
3. Generate. Gemma 4 E2B (the quantization-aware e2b-it-qat build, about 4 GB, runs on a laptop with no GPU) receives the message plus the retrieved cases, with instructions to use only those policies and never invent prices or deadlines.

Three things I learned while testing:

• The first drafts applied the wrong policy. "My vase arrived broken, I want my money back" retrieved both the damaged-item case and a change-of-mind refund case, and Gemma sometimes picked the refund policy: returns accepted if unused, customer pays shipping. Not what you want to tell someone holding a broken vase! Two fixes made it correct and consistent: telling the model to apply the resolution of the most similar case, and lowering the temperature to 0.2.
• A low similarity threshold invites invented answers. At 0.5, the teapot question pulled in unrelated cases and Gemma confidently said the shop had no teapots, something it could not know. Relevant cases scored above 0.63 and noise below 0.58, so I raised the threshold to 0.6: with nothing relevant to read, the model now honestly defers to the owner.
• Retrieval alone isn't enough. Earlier this week I built only the search half: "I want my money back" could not find a note about defective shoes, because embeddings capture what a text is about, not what follows from it. Adding the generation step is what connects "broken" to "here's what we do about it".

This is my first hackathon. I work a lot with AI tools, so I paired with an AI assistant to move fast on the parts that were new to me: pgvector and local models.

Why Does Open Innovation Matter?

For a side hustle, the economics decide everything, and open models change them:

• No per-message cost. Every draft is generated on the owner's laptop. A tiny shop answering 20 emails a day pays nothing per reply, so a cheap flat price is sustainable for both sides. With a paid API, the cost would grow with every customer.
• Customer data stays out of third-party AI APIs. Names, orders and complaints are never sent to an AI provider. (The past cases live in a Postgres database I control, here on Tiger Cloud's free plan; for full privacy, the same code runs against a local Postgres with pgvector.)
• Small enough for a normal laptop. Gemma 4 E2B runs without a GPU, which is the hardware a solo maker actually has.
• Multilingual for free. EmbeddingGemma handles 100+ languages; earlier this week I tested the same setup with Italian notes. A shop answering customers in their own language doesn't need a different product.
• I can swap and tune everything. Model, temperature, threshold and prompt are mine to change, and they were exactly the knobs that fixed the wrong-policy and invented-answer problems.

The trade-off is honest: a bigger closed model might write smoother prose. But for drafts that a human reviews anyway, a free, private, local model is the better deal.

Prize Categories

• Best Use of Gemma
• Best Use of Tiger Data