Git-Voice: Twenty Seconds of Client Voice into One Filed GitHub Issue

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

What I Built

The recurring pain behind client work isn't the bugs — it's the dispatch cost. A client sees something broken on their staging site, describes it in one emotional sentence ("the checkout is broken, fix it ASAP"), and the freelancer spends the next unpaid hour reverse-engineering the sentence: which browser, which route, what console said, whether the coupon even reached the server. Neither side is having a good time. I've been on both sides of that email.

Git-Voice is a small embeddable widget that replaces the sentence with twenty seconds of speech. The developer drops one <script> tag on the staging site. The client clicks a floating mic button, talks while clicking around the broken page, and the system:

1. captures the audio plus real browser telemetry (console output, route, viewport, clicks),
2. locates the suspicious files by searching an architecture index built from the client's repo,
3. drafts an engineering-grade GitHub issue — title, severity, expected vs. actual, numbered reproduction steps, suspected file — and files it, labels included,
4. reads a short spoken confirmation back to the client in their own browser, so they finish feeling heard instead of handed a form.

No forms, no severity dropdowns, no "which browser are you using?" — the telemetry already answers that.

Who would pay for it: freelance developers and tiny agencies juggling 2–10 client staging sites. The pricing is honest about its audience: Hobby (free, public repos, one project — the whole pipeline still runs), Freelancer at $15/mo (private repos, hosted drafting and premium voice, auto-reindex), Agency at $60/mo (ten projects). One recovered debugging hour a month pays for it.

One thing I refused to fake: the billing. Checkout is a clearly-labelled simulation (card digits pass a Luhn check, invoices are issued, nothing touches a real processor). The pricing page says exactly which capabilities the server enforces, and the server actually enforces them — the plan gates in this post are code, not copy.

Demo

The deployed app (Render-web service with docker):

• Live app: https://git-voice-sh7k.onrender.com — try the landing-page demo store widget, sign in with GitHub, create a project from your own repos, watch a report end-to-end.
• Video walkthrough: Demo

Code

Node + Hono backend, React dashboard, one install-anywhere site widget built as a separate ~21 KB bundle, and a Postgres/pgvector-backed index. Apache-2.0 licensed, no payment processor and no stored card data — the simulated checkout says so plainly in its own UI — and 145 backend tests across 18 files.

Repo:- Git-Voice

How I Built It

The brain is Gemma (gemma-4-26b-a4b-it on the Gemini API, open-weight). Every issue that leaves the pipeline is drafted by it — but deliberately at temperature 0, with a hand-rolled JSON extraction step instead of prompt-and-pray parsing. Transcription of uploaded audio uses the free gemini tier, and embeddings (gemini-embedding-001, 768 dims, batched with exponential backoff) build the retrieval layer. I chose Gemini's free tier for the model side and kept every piece I could running locally so the whole thing costs $0 to operate.

The pipeline is a seven-station engine I wrote myself — ingest → transcribe → locate → correlate → draft → publish → confirm — instead of pulling in a workflow framework, because the failure behavior matters more than the orchestration syntax: each station holds its own typed result, the whole run is bounded by a 90-second timeout, and (this is the part I'm most attached to) a deterministic offline triage engine runs first and stays as the final draft. If the model is unreachable, rate-limited, or not configured, a working, honest issue still gets drafted and filed from a rule-based synthesizer. The spoken confirmation reads through the browser's own speech synthesis on every plan — nothing to configure — and spaces out to a server-rendered voice on paid tiers when the deployment carries a speech API key. Every station's state ends up visible in the dashboard; nothing disappears into a spinner.

Retrieval is hybrid on purpose: keyword scoring over a curated "signature" per file — path, exports, error strings, class names — fused with cosine-similarity over their embeddings using Reciprocal Rank Fusion (Cormack et al. 2009, SIGIR), with BM25 weighting underneath (Robertson & Zaragoza 2009). The index itself comes from the repo tarball (public via codeload, private via the owner's own OAuth token), capped at 800 files, chunked into signatures, and stored in Postgres with pgvector.

For agent observability I wired @sentry/node with OpenInference's gen_ai semantic conventions — one span per pipeline station (gen_ai.execute_tool), one for the model call (gen_ai.chat with real token usage), one per agent run — enabled by nothing more than a SENTRY_DSN environment variable, with a strict gate that strips report content from spans by default. Reports belong to the client; telemetry should collect clicks, not conversations.

Why Does Open Innovation Matter?

Three concrete reasons this is an open-weights project and not a wrapper on some closed API's free credits:

It survives without the vendor. The offline triage engine plus the browser's Web Speech APIs mean the $0 Hobby tier is a complete product, not a teaser. When the model quota runs dry, drafts and file matching keep working; when a paid feature is missing, the UI says so — the plan gates are server-side checks. A closed-API-first product would have been a demo that dies in a cold aisle.

It costs exactly nothing to run honestly. Gemma via the free Gemini tier, Render's free Docker web service, browser TTS/STT, open-source pgvector. Being able to build a purchasable product (the actual "side hustle" test) on top of open infrastructure is the difference between a hobby and a hustle.

Users keep their data and their identity. Issues are filed into the developer's own repo under their own GitHub OAuth token — the deployment's credentials never write to a client repo. The embeddings layer searches a curated signature index, not raw source code, so a client's project is never shipped wholesale to a third-party service. Open stores (plain GitHub issues, Postgres + pgvector) mean no lock-in: stop using Git-Voice and your issues, your repo, and your index stay right where they are.

My First User

The first real user was my freelancer friend — someone who has lived through exactly the "client sends one angry sentence" scenario Git-Voice is built for. He got no instructions beyond a link. What he did in his first session: signed in with GitHub, picked a repository from the picker, upgraded the plan to Agency through the simulated checkout (no money moves, by design), created a project, filed reports through the widget, and replayed the spoken confirmations.

He reported back with screenshots and three bugs (which I'd have shipped to production) saying "It was so helpful for me to save time,I've attached the link my client sent me to my copilot but it didn't understand the proper issue and mangled the whole code,took too much time,with your app it creates a cited issue and my coding agent easily patched the bug,now i am just reviewing the changes". Would he pay? Not yet, and I won't pretend otherwise: the checkout is simulated, so no money has moved. What the session did settle is the value pitch — a twenty-second voice report that lands as a labelled, reproducible issue beats the "which browser is this on?" email every week. I'll take the bug list as the more honest compliment.

Prize Categories

• Best Use of Gemma (featured) — the open-weight gemma-4-26b-a4b-it model drafts every single issue at temperature 0, with a deterministic offline synthesizer underneath it so the product never dead-ends.
• Best Use of Render — the whole thing is one Dockerfile: Hono serves the React dashboard, the widget bundle, the API, and the Postgres/pgvector index from a single free-tier web service, deployed from main with health checks and keep-warm.
• Best Use of Sentry Agent Tracing — the pipeline's work is inspectable, not a spinner: @sentry/node emits gen_ai spans for every station run, for the Gemma call (real token usage and finish reasons), and for the agent run itself, with a content gate that keeps report text out of spans by default. Enabling it is one SENTRY_DSN environment variable, and the trace reads like the dashboard's run log.
• Best Use of ElevenLabs — the confirmation voice is plan-aware: paid tiers render an ElevenLabs mp3 server-side when the deployment carries a key, Hobby always speaks through the browser's native speech synthesis, and any failure falls back gracefully — the client always hears their confirmation.
• Best Use of GitHub Copilot — Copilot handled editor-side work (completions, small refactors, test scaffolding) alongside the milestone-driven agent sessions described above; the odd pairing of a fast autocomplete brain and a slow milestone brain turned out to fit how I actually work.Also github cron jobs plays a significant role of my site(preventing render site getting idle after 15min).