The theme for the first Hacktoberfest DEV Challenge is out, and it is Build for a Friend: pick one real person and build something with open-source AI that solves a real problem for them. Submissions close on Monday, October 5 at 06:59 UTC (Sunday 11:59 PM in California), so you have one weekend.
If you work in DevOps, you probably already have this friend. They text you when their website is down, they ask what a CrashLoopBackOff is, or they are the one who gets paged at 3am. This post gives you six project ideas built around people like that. Each one is small enough for a weekend, and each one has a clear answer to the question the judges ask in every entry: why does open matter for what you built?
The rules in 30 seconds
From the challenge page and the launch post:
- The prompt: build something with open-source AI at its core. An open-weight model, an open-source agent framework, local inference, or all three.
- The theme: solve a real problem for one real person. Bonus points if you hand it over and tell us what they said.
- A new project. It must be built during the challenge window. Pull requests to existing projects do not count this year.
- The write-up matters most. Writing quality has the biggest weight in judging. Explain what you built, who it is for, and why open innovation matters for it.
- One submission per challenge. It can enter every partner category it really uses (list them in your submission), but you can win only once per challenge. The organisers point out that partner categories have smaller pools, so the odds there are better.
1. The night-shift digest, for your on-call friend
The friend: someone who carries a pager and wakes up to 40 alerts, 35 of which need nothing from them.
What it does: reads a night of alerts (an Alertmanager webhook log, a PagerDuty export, or a Slack channel export) and writes a one-screen morning summary: what fired, what is already marked resolved, what fired more than three times, and the one thing a human should look at first. Group repeated notifications into alert episodes in plain code first, so one flapping alert does not look like ten incidents.
Why open matters: alert payloads are full of hostnames, customer names and internal URLs. When the model runs locally on your friend's laptop, the alerts do not go to a model provider. That is a sentence your friend's security team will like. (If you add hosted tracing, think about what it records.)
Weekend scope: one JSON file in, one Markdown summary out. Skip live integrations. A cron job that runs at 07:00 is enough.
Partner fits: Gemma (run it locally), Mastra (orchestrate the steps), Sentry Agent Tracing (show the tokens and latency per summary).
Background: We Built an On-Call Agent in Mastra covers what goes wrong when an agent touches production, and the on-call rotation guide explains what a good page looks like.
2. "Is my website OK?", for a relative with a small business
The friend: your aunt, your dad, the friend who runs a bakery. They have a website and a domain, and they find out it is broken when a customer tells them.
What it does: runs four groups of plain checks once a week: does the site answer, is the TLS certificate valid and when does it expire, when does the domain expire (from RDAP, which replaced WHOIS; allow "unknown"), and does the email domain publish SPF and DMARC records (_dmarc.example.com). Then it turns the results into a message they understand. Not "certificate expires in 9 days" but "the security certificate for your website expires on October 14. If it is not renewed, customers will see a warning. Forward this to whoever set up your site."
Why open matters: it can run on a Raspberry Pi or a small server they already have, with no per-request model fees. A small local model is enough to turn a few facts into a friendly paragraph.
Weekend scope: four check groups, one message, one person. The checks are plain code and the model only writes the message. Pass it the check results as structured data and verify that every problem in the message is one the checks found, so it does not invent one. A weekly check is a health check, not uptime monitoring; say so in the message.
Partner fits: DigitalOcean (host the checker on a Droplet), Arduino (an UNO Q on their shelf that glows red when something is wrong is a very good demo video).
Background: the DNS simulator and the TLS handshake simulator show what the checks look at, and DMARCbis Is Here explains which email records matter in 2026.
3. A kubectl coach that will not do the homework, for a junior friend
The friend: someone learning Kubernetes, stuck on their first broken deployment.
What it does: they paste the output of kubectl describe pod <pod> -n <namespace> or kubectl get events -n <namespace> --field-selector involvedObject.name=<pod>. Instead of a fix to copy, the coach explains what the error means and asks one question back: "The pod restarted 6 times. What does the container's last exit code tell you?" They learn to debug, not to paste.
Why open matters: you control the behaviour. With an open model you set the system prompt, you can fine-tune it on good teaching answers, and you can swap models when a better small one comes out. On a laptop they already own, a student pays no per-request fees.
Weekend scope: a CLI that reads stdin. Five real error outputs as test cases: CrashLoopBackOff, ImagePullBackOff, OOMKilled, Pending (insufficient CPU), and a failed readiness probe.
Partner fits: Gemma, and Tinker if you want to fine-tune and show a clear improvement over the base model.
Background: practice the commands in the Kubernetes terminal simulator, and use CrashLoopBackOff with no logs as a test case.
4. An issue triage helper that drafts but never posts, for a maintainer friend
The friend: someone who maintains an open source project. Every October their notifications fill up.
What it does: for each new issue it suggests labels, finds likely duplicates, and drafts a reply ("Can you share the version and a minimal reproduction?"). The maintainer approves or deletes each draft. It never posts on its own, because a bot that comments on its own makes a maintainer's life worse, not better.
Why open matters: with a local model and local embeddings it runs on the maintainer's machine (or a self-hosted runner), and there are no per-request model fees for a project with no budget.
Weekend scope: read the last 200 issues with the GitHub API (state=all, follow pagination, and drop entries that have a pull_request field, because the issues endpoint returns pull requests too), embed them, and run it on new issues from the command line. A web UI is optional.
Partner fits: Mastra (its own category text mentions a workflow that triages GitHub issues), GitHub Copilot (automate it with GitHub Actions), Tiger Data (store embeddings with pgvector for the duplicate search).
Background: this is why Hacktoberfest dropped PR counts this year. Maintainers asked for less noise, so build them a tool that removes some.
5. "What happened at 3am?", for your homelab friend
The friend: someone with a server in a closet that runs Jellyfin, Pi-hole and twelve containers, and something always stopped overnight.
What it does: collects what changed in a time window into one file: journalctl --since "2026-10-03 02:00" --until "2026-10-03 04:00" --no-pager, docker events --since "2026-10-03T02:00:00" --until "2026-10-03T04:00:00", the package manager's history, and recent container restarts. Then it asks a local model one question: what most likely caused the outage, and what is the evidence? Note that Docker keeps only the last 256 events, so on a busy host start recording them to a file now.
Why open matters: server logs are private, and a homelab should not depend on someone else's cloud. This runs on the same box it inspects.
Weekend scope: one shell script that gathers the logs, one prompt, and one answer that cites log lines. Make the model quote the evidence, check in code that each quoted line really is in the file, and let it answer "not enough evidence".
Partner fits: Gemma. This one does not need a partner category to be a strong entry; the overall prize is open to every project.
Background: the Linux terminal simulator and the log aggregation pipeline simulator.
6. A mock interview partner, for a friend looking for a DevOps job
The friend: someone preparing for interviews who needs practice, not another list of questions.
What it does: asks one interview question, listens to the answer, and gives practice feedback: what was good, what was missing, and one follow-up question like a real interviewer would ask.
Why open matters: the questions can come from an open dataset. The DevOps Daily repo is MIT licensed, and its 110 interview questions (in content/interview-questions/) each have a model answer, follow-up questions and common mistakes. Giving the model that reference answer makes its feedback much more grounded than asking it cold. With a local model, practice answers stay on your friend's machine.
Weekend scope: text first. If you have time, add voice with a local speech-to-text model (such as whisper.cpp) so they can practise out loud.
Partner fits: Gemma, and ElevenLabs if you give the interviewer a voice.
Background: browse the questions on the interview questions page before you build.
A starter that works for all six
Every idea above has the same core: give a local model some text and get back a structured answer. With Ollama and a small Gemma 4 model, that is one HTTP call:
ollama pull gemma4:e4b
curl -s http://localhost:11434/api/chat -d '{
"model": "gemma4:e4b",
"stream": false,
"messages": [
{"role": "system", "content": "You summarise on-call alerts for a tired engineer. Use only the facts in the input."},
{"role": "user", "content": "<paste the alerts here>"}
],
"format": {
"type": "object",
"properties": {
"look_at_first": {"type": "string"},
"self_resolved": {"type": "array", "items": {"type": "string"}},
"repeated": {"type": "array", "items": {"type": "string"}}
},
"required": ["look_at_first", "self_resolved", "repeated"]
}
}' | jq -e '.message.content | fromjson'
The format field constrains the model to that JSON shape. The answer comes back as a JSON string in .message.content, which is why the example parses it with fromjson. In your code, parse it, validate it, and check its facts against the input before you show it to anyone. Change the system prompt and the schema, and you have the core of any of the six projects.
How to fit it into one weekend
- Friday evening: talk to your friend. Ask what annoys them, in their words. Write down one sentence: "Every Monday, my dad wants to know if anything is wrong with his website." That sentence is your scope.
- Saturday: build the ugly version. One input, one output, from the command line. Test it on real data from your friend, with their permission.
- Sunday morning: hand it over. Watch them use it. Their first reaction is the best paragraph in your post.
- Sunday afternoon: write. Writing has the most weight. Leave at least three hours for it.
What to put in the write-up
- Who the friend is and the problem, in their words. Ask before you name them or share any of their data.
- Why open, concretely. "It runs on her laptop with no internet" is stronger than "open source is important".
- What did not work. A model that invented a problem, a prompt you had to rewrite. Judges trust posts that show the hard parts.
- A demo: a screenshot, a short video, or a terminal recording.
- What your friend said when you handed it over.
- Your agent session, if you used one. The organisers suggest DevRelay. It is optional, but it helps judges see how you built it.
Next week
A new challenge starts every Monday in October, each with a new theme. We will post DevOps project ideas for each theme on the day it launches, so follow along if you want a head start.
And if you want to practise classic open source pull requests this month (they do not count for the DEV Challenge, but they are still a skill worth having), our 7-day Hacktoberfest challenge gives you one small, reviewed PR a day.
Who are you building for this weekend? Tell us in the comments.
Top comments (1)
tr.ee/dev-to