Coder Legion - Recent posts tagged hf26challenge

I built my girlfriend a local Gemma football analyst that won't make up the stats

Tue, 27 Oct 2026 02:20:22 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I built

MatchMind is a local AI analyst for Brazilian football, built for Bruna Boaventura, my girlfriend.

Bruna had a hard time finding Brazilian clubs' results and historical data. So I built her one place to look things up — and a way to just ask.

MatchMind puts the numbers together and lets her ask questions in Portuguese to an AI that runs on her own computer. You pick a club and get:

the Brasileirão 2026 table, computed from the season's results, with all 20 crests;
recent form and the last three matches with possession, shots, corners, fouls, goal scorers, cards, stadium and referee;
a "Ver escalações" button that loads both line-ups: formation, coach, minutes and player ratings;
the squad with appearances, goals, assists and ratings;
20+ years of Série A history (2003–2024): titles, season-by-season position and coach, the club's top scorers, discipline, and head-to-head records with the scorers of the last meetings;
a chat with Gemma 3 4B running locally through Ollama, which answers only from that data and separates FATO (fact) from INTERPRETAÇÃO (interpretation).

The rule behind everything: the numbers come from data or from deterministic code, never from the model. If something is missing, MatchMind says "Indisponível" instead of guessing.

Demo

A real answer generated locally by Gemma 3 4B (CPU only):

Line-ups for a match, loaded on demand:

Série A history:

What Bruna said

"Interessante, pois traz dados históricos de 2003 até hoje, contendo gols e estatísticas."
("Interesting, because it brings historical data from 2003 until today, with goals and statistics.")

That was exactly the gap she had: the history is what made it useful for her. (To be precise about coverage: the historical dataset runs from 2003 to 2024, and the current 2026 season comes from a separate live source.)

Code

{% github Darrkkens/matchmind %}

Backend: Go (standard library + pgx for an optional PostgreSQL cache).
Frontend: Vue 3 + TypeScript, interface in Brazilian Portuguese.
AI: Gemma 3 4B through Ollama's /api/chat with structured JSON output.
MIT license, CI with go vet, go test -race and the frontend build, plus contributing guide and issue templates.

Quick start: ollama pull gemma3:4b, then go run ./cmd/server in backend/ and npm run dev in frontend/. No account and no API key are needed.

How I built it

OpenFootball (results, CC0)  ──┐
Série A history CSVs (GPL-2.0) ┼─► Go API ─► deterministic stats, table, form
Optional stats API + cache  ───┘      │
                                      ▼
                     compact JSON context for this question
                                      ▼
                        Gemma 3 4B via Ollama (local)
                                      ▼
            Go validates the JSON and adds FATO / INTERPRETAÇÃO

Data I can trust. Results come from OpenFootball (CC0). The 2003–2024 history comes from Adão Duque's Brasileirão dataset, downloaded at runtime. I computed every season's final table from the results, and the champions match the official list for all 22 seasons; the scorers file matches the final score in 100% of matches since 2015. Where the source has gaps (its 2016 and 2024 statistics are mostly zeros), MatchMind drops those averages instead of showing fake numbers.

Linking sources without guessing. Per-match statistics, scorers and line-ups come from an optional API. A match only receives that data when round, opponent, home/away side and final score all agree with OpenFootball. Line-ups abbreviate names ("G. Gómez") while player stats use full names ("Gustavo Gómez"), so I wrote a matcher that understands initials. It links 95% of starters; the rest (nickname vs. legal name) are shown without numbers rather than guessed. Every API response is cached — in PostgreSQL if you run docker compose up — so a finished match costs one request, ever.

Grounding the model. The browser never sends context. For each question, Go rebuilds the club snapshot and sends Gemma a JSON envelope that keeps the data separate from the question and is explicitly treated as untrusted. Gemma returns facts, interpretation and sources_used; Go validates the structure and the allowed source names and adds the labels itself.

What real testing taught me. Mocked tests passed, but running the real model exposed two problems:

Too slow. As I added history, line-ups and cards, a question on a CPU-only machine went past my 240-second timeout. The fix was to make the context depend on the question: the full table, the season history, the head-to-head records, the squad or the cards are only sent when the question is about them. The context for "where are we in the table and how many titles?" dropped from about 11,400 to 5,400 characters, and the answer came back in about three minutes.
Technically true, actually wrong. Gemma answered that Palmeiras "has 4 Brazilian titles". That's the count in the dataset, which only covers 2003–2024; Palmeiras has more. The prompt already said so, but a 4B model doesn't always follow a sentence buried in a prompt. So I renamed the field the model sees to serie_a_titles_2003_2024_only. The next answer said "4 Série A titles between 2003 and 2024" — the answer you see in the screenshot above. When a rule really matters (like flagging sample data from an API test key), Go appends the warning itself instead of trusting the model.

Why does open matter?

It runs on her machine and costs nothing. After ollama pull gemma3:4b, there's no per-question fee, no AI account and no key to protect. The football data sources used by default are open too.
Her questions stay local. With the default settings, the questions and the club data are processed on the same computer. Nothing goes to a model provider.
I control the whole stack. When the model was too slow, I didn't wait for a vendor: I changed what the model sees. When it phrased something misleadingly, I changed the data contract. I can swap in gemma3:12b on a stronger machine with one environment variable.
The trade-off is honest. A 4B model on a CPU is slow (1.5–3 minutes per answer) and can still omit something that is in its context. That's why the numbers on screen come from code, not from the model, and why every answer says which data it used. A big hosted model would answer faster, but it would cost money per question, need an account, and send everything off the machine — for a personal football tool, those trade-offs aren't worth it.

AI assistance

I built MatchMind with the help of an AI coding assistant (Claude Code), which I directed, reviewed and tested throughout. All data, screenshots and the model answer shown above come from running the real application.

Prize categories

Best Use of Gemma — Gemma 3 4B runs locally through Ollama as the analyst at the core of MatchMind. The project shapes its context per question, constrains it with structured JSON output, validates every answer in Go, and documents where the model still fails.

Interview Buddy: Private Interview Practice for a Friend’s First Developer Job

Mon, 26 Oct 2026 04:55:50 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Interview Buddy for a friend preparing for their first software engineering job. The focus is junior .NET / full stack development, especially practising how to explain technical answers clearly and confidently.

The app turns a CV and job description into a short practice interview. You choose technical, behavioural, or mixed questions and a difficulty level, then answer one question at a time.

Each answer receives feedback covering:

What went well.
Technical mistakes or missing points.
How to explain the answer more clearly.
An example improved answer.
One relevant follow-up question.

You can retry a question and finish with a reflection on strengths, topics to revise, and suggested next practice. Behavioural coaching asks the model to use STAR without inventing a personal story. Improved answers must stick to supplied experience or clearly label hypothetical examples.

Privacy is part of the workflow: Save this session locally is optional and unchecked by default. Temporary sessions disappear on refresh. Saved sessions can be revisited or deleted individually, and there is a Delete all local data action. Users can also flag questionable feedback.

The interface uses a calm navy, green, and neutral palette, with readable questions, labelled controls, loading states, and a local-AI connection indicator. A clearly labelled synthetic demo previews the workflow without pretending to assess answers using live AI.

Actual friend feedback:

What helped: “Practising one question at a time made it easier to focus. The clearer answer examples helped me organise my explanations.”
What confused them: “I wasn’t sure whether flagging feedback would correct it or just mark it for review.”
What they would change: “I’d like a hint before answering and a way to practise only the topics I struggled with.”

Demo

Video walkthrough: Watch or download Interview Buddy on GitHub

Direct MP4 link · 74.5 seconds · 1080 × 1920 · silent, with explanatory text.

Created with Remotion using actual captures of the running app’s synthetic workflow: context, saving consent, answers, feedback, retry, flagging, summary, and restored history. This is an edited browser-capture walkthrough, not continuous native screen recording or live AI inference.

The app currently runs locally; it has not been publicly deployed. The repository includes startup instructions, synthetic sample inputs, and a short hand-off walkthrough. The synthetic demo can be explored without downloading a model.

Code

Interview Buddy repository

The repository is public. The Remotion source and synthetic capture assets are included in walkthrough/.

How I Built It

The app uses React and TypeScript for the frontend, Python FastAPI for the backend, and SQLite for sessions the user explicitly chooses to save.

The inference integration uses Ollama with Qwen2.5 7B Instruct, an open-weight model released under Apache 2.0. The model name and local endpoint are configurable. Only the backend sends inference requests to Ollama; there are no cloud AI calls.

The backend requests structured JSON and validates responses with Pydantic. Invalid output gets one repair attempt before a helpful error. The app handles missing models, unavailable Ollama, timeouts, and cancellation. CVs, job descriptions, and answers are treated as untrusted evidence rather than instructions.

I kept the architecture small: no agent framework. Docker Compose provides a convenient setup, and the README includes instructions for running without Docker.

Validation: six mocked tests passed, covering the API workflow, response validation, persistence and deletion, consent, repair, and failure handling. TypeScript checks, frontend formatting, Python lint, the production build, and Compose configuration validation also passed. The dependency audit reported zero vulnerabilities at the time of checking.

Current limits: real inference has not been tested because Ollama was unavailable in the build environment. Docker execution remains unverified. The synthetic workflow was checked in the browser, including retries, flagging, summary, saving, and history restoration. Saved SQLite data is unencrypted, and model feedback can be wrong. The app is intended for single-user localhost use; real friend testing is still pending.

The main lesson was that a focused workflow needs more than question generation: clear privacy choices, useful failure states, and honest feedback labels make practice easier to trust.

Why Does Open Innovation Matter?

CVs and interview answers can contain personal information. Open weights and local inference make it possible to practise without sending those details to a hosted AI provider, while retaining the freedom to inspect the integration and change models.

After dependencies and weights are downloaded, the app is designed to support the core workflow offline. That complete local workflow would not be possible with a hosted-only, closed AI API. It also avoids per-request cloud AI charges, though local hardware, electricity, and inference speed remain tradeoffs.

For this project, open innovation means control over where personal data goes and how the practice tool works. It makes a small, private app possible without tying its usefulness to a cloud service.