DEV Community: Hammad Bin Sajjad

Roll-Call — The AI Teammate That Writes Your Standups From GitHub & Linear

Hammad Bin Sajjad — Mon, 19 Oct 2026 00:47:23 +0000

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

What I Built

Picture the daily standup. The whole team gathers — remote folks dial in — and each person recites what they did yesterday from memory. Nobody likes these meetings. The updates get fudged, the quiet work goes unmentioned, and thirty minutes of everyone's day is spent talking about work instead of doing it.

Roll-Call is the AI teammate that sits in the meeting so nobody has to. Every night, automatically:

It reads the team's real activity — pull requests, commits and pushes from GitHub, issues and comments from Linear. PRs touched today are separated from ongoing work, and every issue is cross-linked to the PR that implements it.
An open-weight Gemma model writes a plain-English standup for each team member.
Everything is stored in MongoDB Atlas — and every report is uploaded to Backboard as a document, so the chat agent is grounded in the team's real history through RAG. Ask "who touched the auth service this week?" and it answers from ingested data — with a tool that pulls live reports straight from MongoDB when it needs fresh facts.
That's the whole standup. One dashboard card per person, ready when you wake up. No meeting.

And this is a real, unedited output — Roll-Call tracking its own development:

Hammad Bin Sajjad

Completed Work

Ingestion of Linear issues and Github PRs (ROL-5): Implemented the ingestion layer, including GitHub PR and Linear issue data retrieval, LLM processing with Gemma, and MongoDB storage. This was completed via PR #2 (branch ROL-5) with commits covering LiteLLM/DB boilerplate and final database integration.

Automate Ingestion using Github Actions Workflow (ROL-6): Set up a GitHub Actions workflow to automate data ingestion at 1 AM UTC. This was implemented in PR #3 (branch ROL-6).

Roll Call Frontend (ROL-8): Implemented the frontend using HTML, CSS, and JS. This work was captured in PR #4 (branch ROL-8), which included updates to system architecture design diagrams.

Roll Call Backend (ROL-7): Implemented the backend APIs, including Backboard Chat integration. This was completed via PR #5 (branch ROL-7), with commits addressing backend implementation, model settings, and error fixes.

Tool output in message bug fix (ROL-10): Fixed a bug regarding tool output in messages via PR #6 (branch ROL-10).

Sentry Agent Tracing (ROL-9): Integrated Sentry error and agent tracing for both ingestion (LiteLLM) and chat (Backboard). This was handled in PR #7 (branch ROL-9), which included fixing Sentry sample-rate crashes and workflow changes.

Ongoing Work

FE and BE Bug Fixes (ROL-10): Ongoing work to address bugs identified during production testing.

Direct Pushes

Pushed a fix for commit duplication to the Roll-Call repository.

Pushed an update to the API URL in the Roll-Call repository.

Note what the model got right: every PR is tied to the Linear issue it implements, completed work is separated from ongoing work, and even the direct pushes (commits that never went through a PR) made it in — while only stating what the data shows. The system prompt forbids inventing activity.

Who pays for this: engineering leads and project managers of small remote teams (5–20 people), and agencies juggling client repos. Existing tools still make humans do the work — typing updates into a form, or sitting through the meeting. Roll-Call reads the sources of truth directly — so nobody has to remember anything, and nobody has to report anything.

Demo

Live on Render: https://roll-call-frontend-2xea.onrender.com

Registration is open — create an account and everything's live. One heads-up: if the backend has been idle, the first request can take 30–60 seconds to wake it up.

Summaries — the standup, already written, one card per member:

Config — manage tracked repos and team members from the UI:

Chat — the agent answers from ingested history, citing the PRs and issues behind every answer:

Code

hammadbinsajjad / Roll-Call

Roll-Call

Roll-Call is an AI team-reporting agent. It automatically ingests your team's daily activity from GitHub (pull requests, commits, direct pushes) and Linear (issues comments), generates a plain-English standup summary per member with an open-weight Gemma model, stores everything in MongoDB Atlas, and exposes it through a chat interface where an agent — grounded in the ingested data via RAG — answers questions about who worked on what, and when.

Architecture

(Source: architecture/system-data-flow-design.png)

Screenshots

Summaries — daily standup dashboard, one card per team member:

Config — manage the tracked repos and team members:

Chat — ask the agent about the team's work, grounded in the ingested data:

How it works

Ingestion (ingestion/) — a scheduled GitHub Actions workflow runs nightly at 01:00 UTC (reporting the completed previous day)
- github.py walks open PRs per repo, marking the ones touched today (commits reviews, merges) vs. ongoing; direct pushes…

View on GitHub

ingestion/      Nightly pipeline — GitHub + Linear → Gemma → MongoDB → Backboard
backend/        FastAPI app — auth, summaries, config, chats, /embed
frontend/       Static UI, no build step
.github/        Workflows — nightly ingestion + deploy pipelines
render.yaml     Render Blueprint — both services

How I Built It

One loop: collect → summarize → store → ground → answer. The whole data flow:

The pieces:

Nightly ingestion (GitHub Actions, 01:00 UTC). Collectors pull GitHub PRs/commits/pushes and Linear issues/comments, cross-link issues to the PRs implementing them, and build one payload per member. Then Gemma writes each standup through litellm. This is the only AI part that can work fully locally — the chat can't run locally, because it depends on Backboard. During development I tested the ingestion with Gemma 4 E4B on my own machine; the hosted pipeline runs Gemma 4 26B A4B via OpenRouter. Members with no activity skip the LLM call entirely — quiet days cost nothing.
Storage (MongoDB Atlas). One roll_call database shared by the pipeline (writer) and the API (reader). Each report is also POSTed to the backend's /embed endpoint — machine-to-machine, secret-token guarded — which uploads it to Backboard, replacing (not duplicating) the old document on re-runs.
Chat agent (Backboard). Chats map 1:1 to Backboard threads; history lives there, grounded in the uploaded reports. The assistant has one tool — get_daily_summaries — querying live reports from MongoDB. The chat runs on Gemma 4 26B A4B via OpenRouter, the only model this assistant runs.
Backend (FastAPI). The only thing the browser talks to: JWT auth, per-user quotas checked in MongoDB before any AI call (rejected users cost nothing), and rate-limited chat endpoints.
Frontend. Plain HTML/CSS/vanilla JS, no build step — deploys to static hosting as-is, with a "Terminal Green" dark theme.
Hosting & deploys (Render + GitHub Actions). render.yaml defines both services. Auto-deploys are off — pushes to main trigger Actions workflows that fire each service's deploy hook, so the same automation runs the data pipeline and the releases.
Sentry Agent Tracing on both AI paths. The ingestion Gemma calls flow through the litellm integration; the Backboard client (no Sentry integration of its own) got custom gen_ai span instrumentation with conversation IDs. Both AI paths show up as first-class traces in one dashboard.

A small footnote I enjoy: even the tooling behind the project is open — the local Gemma test ran on llama.cpp, the architecture diagram above was drawn in Drawy (open source, from KDE), and the code was written primarily with GLM 5.3, GLM 5.3 Flash, and Mimo V2.6 Pro — all open-weight models too.

Both sides, running live — the nightly ingestion runs, the deployments to Render, and both AI paths traced in Sentry:

Why Does Open Innovation Matter?

1. Private data stays on hardware you control. Teams can have private data they don't want to send to a closed service — or to any server they don't control. Because Gemma is an open model, they don't have to: they can run it on their own computers, or self-host on their own servers. In my project, the ingestion part — the step that reads private GitHub and Linear activity — can be run fully locally. I tested it during development with Gemma 4 E4B on my own machine, with nothing leaving it.

2. One model, many providers — and cost goes where it matters. Open models work across providers, and not every provider is the same — so you never get stuck with one provider and their pricing. Roll-Call has two uses of AI: the ingestion and the chat. The ingestion happens overnight, when nobody's watching — so it can use a cheaper model or tier — while the faster, more capable models are kept for the customer-facing chat agent. That puts the cost where it matters. This flexibility isn't as extensive with closed providers. OpenRouter, the provider I used, has tiers made for exactly this.

Prize Categories

Entering:

Best Use of Gemma — Gemma powers both AI paths: the standup ingestion — which I tested fully locally with Gemma 4 E4B through litellm, and which runs hosted on Gemma 4 26B A4B via OpenRouter — and the chat agent on Backboard, running Gemma 4 26B A4B via OpenRouter.
Best Use of Render — the whole product runs on two Render services defined in one render.yaml Blueprint (FastAPI web service + static site), with GitHub Actions deploy hooks for deliberate releases.
Best Use of GitHub Copilot — GitHub runs the automation: Actions powers the nightly data-ingestion pipeline (collect GitHub + Linear → Gemma summary → MongoDB → RAG upload) and the deploy pipelines for both services. One cron, one push to main, and the system works while you sleep.
Best Use of Backboard — the agent's memory and RAG: every ingested GitHub/Linear report is uploaded as a Backboard document, chats run on Backboard threads with a get_daily_summaries tool
Best Use of MongoDB Atlas — the primary database: one roll_call DB written by the ingestion pipeline and read by the API (repos, team members, daily reports, users, chats), plus the assistant's live tool queries straight from the summaries collection.
Best Use of Sentry Agent Tracing — both AI paths are traced: the ingestion Gemma calls through the litellm integration, and the Backboard chat client through custom gen_ai span instrumentation with conversation IDs and error typing.

Kitchen Companion

Hammad Bin Sajjad — Mon, 05 Oct 2026 00:01:33 +0000

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

What I Built

Kitchen Companion — a kitchen assistant for my mother, who kept asking me the same question over WhatsApp: "Mere paas aloo, tamatar aur thora chawal bacha hai — kya banaun?"

Her fridge is a moving target: leftovers, half-used things, whatever she bought that week. So I built her an app where she photographs her fridge, fixes the detected ingredient list on screen (the vision model sometimes "sees" things that aren't there — she removes those with one tap), and then chats with a warm kitchen companion that suggests meals in Roman Urdu — Urdu written in Latin letters, the way Pakistanis actually text. She can follow up by typing or speaking ("steps chahiye", "tamatar nahi hai", "guests aa rahe hain"), and the ingredient list and suggestions stay in sync as the conversation evolves.

It solves the actual problem: "what can I cook with THIS, right now" — not a generic recipe search engine.

Demo

Video Recording: https://drive.google.com/file/d/1CaxfYjIUAkL_-7jGiiiQ0QuF2bavQP8z/view?usp=drive_link

Code

hammadbinsajjad / Kitchen-Companion

Kitchen Companion

Photograph your fridge, fix the detected ingredient list on screen, and get meal suggestions in Roman Urdu from a kitchen companion chatbot that answers typed and spoken follow-ups.

All AI runs locally on your laptop via llama.cpp — zero cloud calls at runtime.

Run it

Start the model server (first run downloads the model from Hugging Face):
```
./run_model.sh
```

Start the app (separate terminal):

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/uvicorn server:app --host 0.0.0.0 --port 8000

On your phone (same Wi-Fi): open http://<laptop-ip>:8000.

How it works

One AI endpoint, POST /api/chat:

images attached → vision turn: returns the detected ingredient list
text / audio clip → conversation turn: Roman Urdu reply + the full current ingredient list (so spoken or typed corrections like "tamatar nahi hai" update the chips; manual chip ✕ / + add work too)
images + text/audio → vision turn that also…

View on GitHub

Zero build tooling: plain HTML/JS frontend served by a small FastAPI backend that talks to llama.cpp. One command starts the model, one starts the app.

How I Built It

Model: Gemma 4 E4B (QAT GGUF) running via llama.cpp's llama serve on my laptop — chosen because it's natively multimodal: the same model handles vision (fridge photos) and audio (spoken follow-ups). No speech-to-text layer anywhere — her voice goes straight into the model as input_audio, and the browser records/re-encodes it to WAV with vanilla JS.
One endpoint: the whole app is a single POST /api/chat. The request shape decides the turn — images attached = vision turn, text/audio = conversation turn, both = a vision turn that also acknowledges the note. No intent classifier, no agent framework — routing that can be read off the request metadata should never be inferred.
Structured output: every response is schema-constrained JSON {reply, dishes, ingredients}. Dish suggestions are separate objects rendered as tappable cards (tap = "steps chahiye"), and the ingredient list rides along in every turn so conversational corrections ("chawal nahi hai") update the chips. Plus defensive parsing for the real world: brace-residue stripping, truncation salvage, case-insensitive dedupe.
Human-in-the-loop by design: the edited chip list — not the raw model output — feeds the suggestion pass. The model proposes; my mother disposes.
Stateless backend: conversation history lives in the frontend and is re-sent every turn. Config lives in exactly two files (config.py / config.js).
Tested mobile-first in DevTools responsive mode for Pixel 8/9 (412 x 915); my mother's phone is the real target.

Why Does Open Innovation Matter?

Because the model is open and runs locally, every photo she takes — her kitchen, her cupboards, the inside of her fridge — never leaves her home network. No cloud, no uploads, no server somewhere holding her family's life in a data center. What's in her fridge is nobody's business but her own, and open weights are the only way that's possible.

And it just keeps working. No internet? No problem — the laptop on her Wi-Fi is the entire system. The app doesn't care if the connection drops, if a service is down for maintenance, or if a provider changes its pricing overnight. For a tool that lives in the busiest room of a house and gets used daily by my mother, that reliability isn't a nice-to-have; it's the whole point.

A closed API would have meant mailing her kitchen photos to someone else's server on every single use — and a companion that dies the moment the connection does. Open innovation made this private and hers — which was the entire point of building for a friend.

Prize Categories

Best Use of Gemma