Photos Never Leave Your Machine: ListingForge Writes E-commerce Copy with Open-Source Models

E-commerce sellers spend a lot of time every day writing product titles, selling points, and descriptions—and since photos often involve unreleased products, uploading them to the cloud never feels safe. Developer Jha-2022 shared an open-source project on Dev.to called ListingForge: photo understanding and copy generation all happen on the seller's own laptop, the model weights are open-source, and there are no per-use fees. This article is based on the author's real testing notes, breaking down its design trade-offs, the pitfalls encountered, and the real value of local-first AI tools in e-commerce scenarios.

Why Keep Photos on the Local Machine

ListingForge's core proposition is straightforward: a seller's product photos should not leave her computer. For a seller launching 60 products a month, at roughly 40 minutes per listing, that adds up to about 40 hours a month. ListingForge turns this work into a single batch task—the seller can start it and go pack and ship orders. The author did the math on pricing: batches over 10 items require a ₹499/month license, and the monthly fee pays for itself within the first hour saved.

This math works because the target users are cost-sensitive and launch new products frequently. More importantly, there's privacy: a seller with 200 products who needs to regenerate copy repeatedly would see costs pile up quickly under per-call pricing—and photos of unreleased products would sit on someone else's servers. When comparing against closed-source frontier models, the author acknowledges that hosted models can write a listing in about 5 seconds, while his CPU laptop takes a median of about 75 seconds, and photo understanding may be a bit more accurate. But he believes that for this product, that trade-off is precisely its reason for existing.

Rule Engine: Models Make Mistakes, But Sellers Shouldn't See Them

Small local models have clear capability boundaries, and ListingForge's approach is to wrap a rule engine around the model. The author gives a real example: in the first test on Amazon India, the model wrote 163 characters for Etsy's 140-character title field and generated 14 tags instead of 13, one of which—handmade-soy-candle-lavender—was 28 characters long. The rule engine truncates the title at the last complete word within 140 characters, drops excess tags, and rejects overlong tags, so what the seller ultimately sees is a compliant listing.

Another easily overlooked detail is byte limits. Amazon's 250-byte backend field counts by UTF-8 bytes, and each Devanagari character takes 3 bytes, so a Hindi search term that looks short can actually exceed the limit. The rule engine therefore counts bytes instead of characters. These engineering details show that the competitiveness of a local-model product isn't just in the model itself, but more in the deterministic constraint layer built around platform rules.

UTF-8 byte counting: Amazon backend field length limits are often measured in bytes rather than characters. UTF-8 is a variable-length encoding: ASCII characters (such as English letters) take 1 byte, while non-Latin characters such as Devanagari (Hindi) typically take 3 bytes. Therefore, a Hindi title that appears to have only 50 characters may actually occupy 150 bytes, exceeding the 250-byte limit. The rule engine must calculate length in bytes and ensure that truncation does not break the integrity of multibyte characters; otherwise it will produce garbled text. This requires developers to understand the underlying differences in character encoding rather than simply calling a string length function.

Three Language and Hallucination Problems, and How the Author Fixed Them

The author candidly lists the mistakes the model made, several of which are valuable references for anyone building multilingual e-commerce tools.

Hallucinated materials are the most dangerous category: the model described a painted MDF box as "hand-carved teak." The author added two measures: first, a prompt rule to describe only visible content; second, an editable material field that the seller must confirm, providing a checkpoint before the listing is finalized.

Hinglish consistency required the most prompt tuning. Without examples, the model either drifted toward formal Hindi or wrote stiff, translationese English. The author solved this by adding two few-shot examples:

• Before: "Yeh candle bahut hi sundar aur prakritik hai."
• After: "Ghar ko banaye cozy: handmade soy candle, lavender ki shaandaar khushboo ke saath. Diwali gifting ke liye perfect!"

But sometimes the model drifted back to pure Hindi by the third bullet, so the author's fix was to repeat the "Hinglish, Roman script" instruction at the end of the writer prompt. On CPU speed, a single listing takes a median of about 75 seconds, which suits the start-a-batch-and-walk-away scenario—this is also why the SSE progress stream exists—but single-item fine-tuning is on the slow side.

Few-shot prompting: Providing a small number of input-output examples in the prompt so the model imitates the style and format of the examples. For mixed languages like Hinglish, examples can significantly stabilize output and prevent the model from wavering between formal Hindi and translationese English. After the author added two examples, the model-generated titles sounded closer to the seller's spoken style. The cost of few-shot prompting is context window usage, but it is lighter than fine-tuning and suits rapid iteration with small local models.

SSE (Server-Sent Events): An HTTP-based server push technology that allows the server to send a one-way stream of events to the client in real time. In ListingForge, SSE is used to push batch generation progress to the seller's frontend, because generating a single listing takes about 75 seconds and a batch task can last several minutes. Compared with polling, SSE reduces wasted requests, lets the seller see in real time which product is currently being processed, and delivers results immediately upon completion.

Real Product Testing: What 12 Products Revealed

The author ran real tests with his cousin's block-printing shop in Jaipur. Out of 12 products, his cousin edited 5 titles, mainly to add the brand name; 9 of the 12 bullet sets were kept unchanged; and she rewrote the "story" paragraph for 3 products to sound more like her own voice. This result directly drove a product change: the brand voice profile needs more example sentences, and the recommended sample count was raised from 2 to 4.

The first real user was this cousin, who sells block-printed kurtas on Meesho and had 12 products waiting for the Diwali launch. ListingForge generated 12 Meesho listings in about the 15 minutes she spent packing orders. She reported that the Hinglish titles sounded like she wrote them herself, but wanted the material field to become mandatory—which is exactly why the "confirm materials" step exists. Her use also exposed two bugs: ZIP imports failed when folder names contained spaces, and the batch progress bar got stuck on the last product. Both have now been fixed.

Trade-offs and Lessons of the Open-Weight Route

ListingForge's code is public on GitHub (Jha-2022/ListingForge); both vision and writing run on open-weight models on the seller's machine, with no per-item fees and no photo uploads. In the category description for the competition, the author left an honest footnote: if Gemma is to be used as a selling point, same-methodology testing must come first—for example, switching to gemma3:12b via the VLM_MODEL variable and comparing per-item time and the number of hallucinated attributes across the same 30 products. This "don't write it if you haven't tested it" attitude is rare in open-source project promotion.

From a product perspective, ListingForge's value isn't in how strong the model is, but in turning "privacy never leaves the machine" into a usable workflow: batch tasks, progress streams, platform rule validation, and seller confirmation steps—each layer compensating for the weaknesses of small local models. For AI tools aimed at small and medium sellers, this may be more practical than chasing single-item generation speed.

Open-weight models: AI models whose parameters (weights) are publicly downloadable, such as the Gemma and Llama series. Unlike closed-source APIs, open weights can run on local hardware, keep data on the device, and incur no per-call fees. The cost is that you must handle inference optimization, hardware compatibility, and model selection yourself. ListingForge uses open-weight models precisely to deliver on the privacy promise that "photos never leave the machine" while avoiding the accumulation of per-item costs.