GigLift: Using Gemma to Turn Hinglish Messages into Clear Task Briefs

Small shop owners in India don't write job postings. They just send a WhatsApp message: "logo bana do dukaan ke liye, 1500 tak, Friday tak chahiye" (make a logo for the shop, under 1500, needed by Friday).

GigLift is a small task platform aimed at students, and it starts from this very message. It turns messy colloquial requests into formal task briefs: deliverables, skill requirements, budget, deadline, and the key questions the shop owner forgot to answer. The shop owner confirms and corrects before anything is published—nothing goes public until then. Students see tasks by match quality and submit proposals; only after the shop owner picks someone do both parties exchange phone numbers, and payment happens offline.

The Problem: Vague Requests Leave Both Sides Guessing

The project starts from a very concrete pain point: a single WhatsApp message is missing half the information a freelancer needs. Students can only guess when quoting, and at delivery time both sides argue over "what exactly did you want." The author writes in the original article that a clear upfront brief costs almost nothing but heads off most later disputes.

The target users are small shop owners willing to pay for small jobs—designing a logo, a menu card, editing 8 short videos, transcribing 40 pages of text—typically priced between 500 and 3,000 rupees. The side income goes to the students.

You might not notice the project's honesty: GigLift itself doesn't make money, has no real customers yet, and no one has paid through it. It's a deployed, working prototype, not a mature product.

Tech Architecture: Django + HTMX + a Single-File AI Module

The stack is quite restrained: Django with HTMX and SQLite, deployed on Render's free tier. All AI logic lives in one file, core/llm.py, using only the standard library with no SDK. The model is Gemma (gemma-4-26b-a4b-it), called through Google-hosted Gemini API. If the API key is missing or the call fails, a rule-based fallback takes over, and the page footer shows AI: offline instead of AI: gemma.

Core Design: Don't Let the Model Decide the Numbers

The project's most valuable design decision comes from an early lesson: let the model give a price, and it will give a price—even if the customer never mentioned one. The author therefore completely changed strategy: budget and deadline are not left to the model's judgment.

If the customer states a budget or deadline in the original text, the rule set in core/extract.py extracts it directly from the text, and the model has no authority to change it. These rules handle English, Hinglish, and Devanagari numerals: 1500 tak, ₹१२००, parso (day after tomorrow), agle hafte (next week), Friday tak.

If the customer didn't write one, any number the model produces is labeled "rough guess, not a real price" and the customer is prompted to fill it in. If the model's generated deliverables contain a number that doesn't exist in the customer's message, that line is simply dropped. What's left to Gemma is what rules can't do: understanding Hinglish requests and writing deliverable lists and questions to confirm.

This division of labor is worth borrowing for most AI applications—give deterministic decisions to code, leave language understanding to the model.

HTMX is a lightweight frontend library that lets developers make AJAX requests directly on HTML tags via attributes (such as hx-get, hx-post) and update parts of the page with returned HTML fragments, without writing lots of JavaScript or pulling in frameworks like React/Vue. In GigLift, HTMX naturally pairs with Django's template rendering: the Django backend returns rendered HTML fragments, and HTMX swaps in the corresponding page regions—enabling interactions like editing task briefs and updating status. This combination lets a solo developer build a responsive web app with minimal frontend complexity while keeping the codebase simple and the deployment light.

SQLite is a Python built-in embedded relational database where the entire database is a single file, requiring no separate database server process. For a prototype like GigLift, SQLite with the Django ORM is enough to support development and demos, and deploying on Render's free tier needs no extra database service configuration. But note that Render free instances have an ephemeral filesystem—redeploying resets the data, which also explains the note in the original article that "redeploying resets the data."

Render is a cloud platform with automatic deployment that offers a free-tier web service. Free instances sleep when there's no traffic, so the first visit requires a cold start—hence the original article's warning that "the first visit may take a minute."

Hinglish is a colloquial written form mixing Hindi and English, widely popular in Indian cities and on social media, commonly seen in WhatsApp chats. It has no unified orthography: the same word may be spelled multiple ways (e.g., hai/hain), numbers may be expressed in English (1500), Devanagari (१५००), or word form (paanch hazar meaning 5000), and time expressions often mix English and Hindi (Friday tak, parso, agle hafte). This non-standardization poses challenges for rule extraction—and is exactly why model-based language understanding is needed.

Devanagari is the script used to write Hindi, Marathi, and others, with numerals ०१२३४५६७८९ corresponding to 0 through 9. In text processing, Devanagari numerals must first be normalized to Arabic numerals before rule matching for budget and deadline. The ₹१२०० mentioned in the original is a combination of the rupee symbol and Devanagari numerals.

Evaluation: Real Results on the Held-Out Set

The author hand-wrote 30 briefs to refine the rules, then froze extract.py (hash recorded in eval/FROZEN.txt) and wrote 32 new briefs for a one-time evaluation.

Held-out set (32 briefs)	Old regex	New rules
Explicit budget read correctly (25)	11	22
Explicit budget read incorrectly	14	0
Fabricated when no budget given (7)	7	0
Explicit deadline read correctly (27)	8	25
Explicit deadline read incorrectly	19	0
Fabricated when no deadline given (5)	5	0
Crashes	1	0

Then the full pipeline was run with real Gemma, with all 32 briefs processed by the model: 22 of 25 budgets read correctly, 25 of 27 deadlines read correctly, zero errors, zero fabrications. This matches the pure-rule results, exactly as intended—Gemma cannot change the numbers the customer wrote.

The 5 misses were paanch hazar (amount in word form), 1800 mein ho jaye, due 25 Oct, within 48 hours. The author's explanation is key: a miss means the app asks the customer a follow-up question, rather than showing a wrong number.

Limitations of the Evaluation

The author proactively acknowledges the methodology's weaknesses: the rules and test briefs were written by the same person, so the held-out results are optimistic; the evaluation only measures numbers and hasn't assessed the quality of Gemma-generated open questions, skills, and deliverables. Next steps include real customer messages and delivery acceptance—where students describe what was delivered and the model flags each item as complete or missing.

A held-out set is a common practice in machine learning evaluation: use part of the data during development (here, the author's hand-written 30 briefs) to tune rules, then freeze the rules and take a fresh batch of data never used in development (32 new briefs) for a one-time evaluation, to estimate real performance on unseen data. Freezing the rules (hash recorded in eval/FROZEN.txt) prevents secretly modifying them after evaluation and re-running, ensuring reproducibility and credibility. However, if the held-out set and the development set come from the same author and the same style, the distributions remain close and results will be optimistic—precisely the limitation the original article admits.

Regular expressions (regex) are tools for describing string matching patterns; the "old regex" in the original refers to the first version of the regex-based budget and deadline extraction approach. Regex excels at fixed-format text but covers Hinglish's diverse expressions poorly (e.g., 1800 mein ho jaye, within 48 hours), easily missing or mis-matching, which is why the author later switched to a more structured rule set.

Pitfalls Along the Way

These details are useful for developers building similar apps:

• The first offline regex read the "rs" in "posters, 4" as rupees and crashed outright.
• On Windows, the scoring script read briefs with the wrong encoding, corrupting the ₹ symbol and dropping the budget score from 22 to 16.
• Gemma's early replies couldn't be parsed as JSON at all, so all briefs silently fell back to offline rules without anyone noticing. The author rewrote the parser to extract the largest valid JSON object in the reply, and made the evaluation print which backend actually served the request.
• The author once published a screenshot containing an API key, then revoked the key.

Basic security work was also done: CSP with nonces, per-session and per-IP rate limiting, ownership checks on edit and hire operations, plus 24 Django tests and 7 rule tests.

What Open Models Mean for This Project

The author didn't compare against closed models, so makes no claim that Gemma is stronger—instead listing what open source actually changes:

Design doesn't need a frontier model. Because the numbers are decided by code, the model only needs to read messy requests and write short briefs—a mid-sized open model suffices. The model is therefore swappable—change a single GEMMA_MODEL environment variable to switch.

Costs are controllable. A task runs 600 rupees, and right now the free API key makes each brief cost nothing to generate; open weights mean you won't be stuck if the free quota changes, and you can run the same prompts on your own hardware.

Privacy is the biggest unfinished item. These messages often contain phone numbers, and currently the text is sent to Google's API, leaving the author's own server. The author hopes to use a local model in the future so shop owners' messages never enter a closed vendor's systems. The Gemma call is centralized in one function, so pointing it at a local model only requires rewriting that function without touching the prompts—but this step hasn't been done yet.

Summary

GigLift is a small but complete open-source prototype: MIT licensed, code public, evaluation reproducible. What's most noteworthy isn't the feature scope but that design principle—let the model do language understanding, let code hold the line on numbers. For AI applications facing real users and involving money, this matters more in practice than chasing a bigger model.

The project is live on Render's free tier; note that the first visit may take a minute, and redeploying resets the data.

One-line Summary

GigLift uses Gemma to turn Hinglish messages into task briefs, with rules holding the numbers and the model handling only language understanding.

Paragraph Summary

GigLift is a small task-platform prototype for Indian students that turns messy Hinglish WhatsApp messages from shop owners into structured task briefs with deliverables, skills, budget, and deadlines. Its core design principle: budget and deadline are extracted from the original text by deterministic rules, and the model has no authority to change or fabricate them—if not provided, they're explicitly labeled as guesses and the customer is asked. The stack is Django, HTMX, and SQLite, with all AI logic in a single file calling the Gemma model and falling back to offline rules on failure. On a 32-brief held-out set, explicit budgets were read correctly 22/25 and deadlines 25/27, with zero errors and zero fabrications. The project is MIT licensed and deployed but has no real paying customers yet, and the author acknowledges the evaluation's optimistic bias from a self-written test set.