The theme for Week 2 of the Hacktoberfest DEV Challenge is out: Side Hustle. Build something with open-weight models or open-source AI that someone would actually pay for. Submissions are due by October 18, 2026 at 11:59 PM PDT.
This one suits people in DevOps. Every small business, freelancer and two-person SaaS has an ops job it hates and cannot afford to hire for: the cloud bill nobody reads, the security questionnaire that blocks a deal, the Terraform change the client must approve but cannot understand. Below are six ideas, each one small enough for a week of evenings, each one with a customer you can name, and each one with 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 Week 2 launch post:
- The prompt: build something with open-source AI at its core: an open-weight model, an open-source agent harness or framework, local inference, or all three. The open pieces should be what makes the project work.
- The theme: something someone would actually pay for. Think small, specific and useful: a real problem for a freelancer, a small business owner, a niche community or a friend with a tedious task.
- The bonus: land your first user. Put it in front of someone, let them use it, and tell the judges how it went. Did they pay? Would they? What did they ask for next?
- A new project, built during the challenge week. Pull requests to existing projects do not count this year. Teams of up to four can enter, with one submission per team.
- What the entry must include: a link to a deployed project or a video demo, a link to the code repository, and why open innovation matters for the project. Start from the submission template in the launch post; it adds the required tags.
- The write-up matters most. Writing quality has the biggest weight. Explain why open innovation matters for what you built: does running your own model keep costs low enough that the business works, keep customer data private, let you fine-tune for a niche, or keep you out of someone else's pricing?
- One submission per challenge. It is in the running for the overall prize and every partner category it really uses, but it can win only once per challenge. Several partners give participants free credits, and you claim them at hacktoberfest.com/my/promos.
1. "Who is sending email as us?", for small businesses and the IT people they hire
The customer: a small business whose invoices land in spam, or the freelance IT person who looks after twenty of them.
The problem: they published a DMARC record with a rua= address because a guide told them to, and now mailbox providers send them aggregate reports every day. The reports are compressed XML files in a mailbox nobody opens. Inside is most of the answer to the questions they care about: which servers the big mailbox providers saw sending mail as their domain, which of those failed SPF and DKIM, and how close they are to moving from monitoring to enforcement.
What it does: reads the report mailbox, unpacks and parses the XML with plain code, and groups the results by sender. Reverse DNS and an IP lookup turn addresses into names, so the summary can say "your helpdesk tool sends about 300 emails a week as you and fails DKIM" or "a server you do not use tried to send as you 40 times". A local model writes the weekly summary in plain language and says what to ask each vendor for. Plain code, not the model, suggests p=quarantine, and only when every sender on the owner's own list of services passes. Forwarded mail can fail for reasons that are not the sender's fault, so the owner confirms before anything changes.
Why open matters: these reports show which services send mail as the business and how much they send. That is a map of its vendors. A local model keeps it in-house, and the cost per domain stays low enough to charge a few euros a month, which is the only price a very small business pays for email plumbing.
Week scope: one domain, a folder of real reports (yours, or a friend's after they agree), one weekly summary. The aggregate report format is in RFC 9990.
Your first user: the friend who asks you why their invoices go to spam.
Partner fits: Temporal (a daily fetch that retries when the mailbox is slow), MongoDB Atlas (store parsed reports so you can show a trend, if the customer is fine with a hosted database), a .tech domain (put the report page live on a domain you claimed through Hacktoberfest).
Background: our DMARCbis guide covers what changed in DMARC this year, and the SMTP flow simulator shows where SPF, DKIM and DMARC are checked.
2. A cloud bill cleaner that is paid from the savings, for small companies on AWS
The customer: a company with a cloud bill large enough to hurt and too small to hire a FinOps person.
The problem: the bill grows a little every month. Nobody knows which old snapshots, unattached volumes and idle load balancers they still pay for. Public IP addresses add up too: since February 2024, AWS charges $0.005 per hour for every AWS-provided public IPv4 address, in use or idle.
What it does: reads a billing export plus a read-only inventory the customer exports themselves (for example, aws ec2 describe-volumes --filters Name=status,Values=available lists volumes that are not attached to anything). Plain rules match the two and find candidates: what probably costs money for nothing, and how much per month. A bill alone cannot prove that something is unused, so the report says what to check before anyone deletes it. A founder can read it in five minutes, and for each candidate it drafts the ticket for the engineer who will check it. Read the FOCUS billing format if you can, so one parser works for more than one cloud.
Why open matters: a billing export shows how big the company is, what it runs, and which vendors it uses. Ship the tool as a CLI that the customer runs on their own laptop with a local model. That removes the hardest sales question: "you want read access to my AWS account?" It also lets you charge a share of the first month's savings, because your own cost per report is small.
Week scope: one export, one inventory, five rules, one report. Use your own account or a friend's, and remove account IDs and resource names from anything you put in the post.
Your first user: any founder who has said "our AWS bill is too high" in the last month.
Partner fits: TabPFN (forecast next month's bill from the daily cost history, which is the CSV use case its category asks for; its API is hosted, so send only daily totals, and its free key is for non-commercial use, so say how you would license it if this became a business), DigitalOcean (host the report page or the model).
Background: our guide to AWS Cost Explorer and Budgets shows the alerts your customer should have set up already.
3. A security questionnaire assistant, for founders of small B2B SaaS
The customer: a two-to-ten person SaaS company that sells to bigger companies.
The problem: every big deal brings a security questionnaire: a spreadsheet with hundreds of rows such as "Do you enforce MFA for all administrative access?" The founder fills it in at night, copies answers from the last one, and is not sure all of them are still true.
What it does: you index the company's own evidence: policies, runbooks, Terraform, CI configuration. For each row, the tool finds the files that answer it and drafts an answer that cites them. When it finds no evidence, it writes "No evidence found" and highlights the row. It never drafts "Yes" without a quoted excerpt, because a wrong "Yes" in a questionnaire is worse than a blank. A policy can describe a control that was planned but never deployed, so the tool also shows how old each source is, and a person approves every answer before it goes out.
Why open matters: these documents describe the company's security gaps, and the questionnaire itself often comes under NDA. Neither should go to a third-party API. With a local model and a local database, everything stays on the founder's laptop.
Week scope: one public questionnaire format, 30 rows, one small evidence folder. Hybrid search helps a lot here: vector search finds "two-factor" when the row says "MFA", and keyword search finds exact control IDs such as "CC6.1".
Your first user: a friend at a startup who has a questionnaire open right now. Ask them how many hours the last one took. That number is your price.
Partner fits: Tiger Data (pgvector plus hybrid keyword and vector search is exactly this retrieval), MongoDB Atlas (Atlas Vector Search for the same job), Gemma (draft the answers locally). Tiger Data and Atlas are hosted, so for the demo use a sample evidence folder, and in the post say where a real customer's data would live.
Background: SSO is usually the next question on those spreadsheets. Our guide on adding SAML and SCIM before it costs you a deal covers that part.
4. A Terraform plan explainer for client sign-off, for freelance infrastructure consultants
The customer: a freelancer or small agency that runs infrastructure for clients who must approve changes but cannot read a plan.
The problem: the client sees "3 to add, 1 to change, 2 to destroy" and either approves everything or blocks everything. Neither is safe.
What it does: a GitHub Action runs on every pull request. Plain code reads the plan JSON, lists each change, and applies the rules: anything that deletes or replaces a resource needs the client's sign-off. A local model writes a short comment the client can understand, with the questions they must answer before approval: "This replaces the orders database. Do you have a backup from today?"
Why open matters: HashiCorp's own terraform show documentation warns that with -json, sensitive values in state are shown in plain text. Even so, send the model only resource addresses and actions, never values. A self-hosted model on your own runner keeps the rest of the plan inside the client's CI. It works the same way with OpenTofu.
Week scope: one repository, three rules, one comment format. The starter below does the core of it.
Your first user: a consultant friend, or your own side project with a non-technical co-founder.
Partner fits: GitHub Copilot (its category includes automating your project with GitHub Actions), Gemma (the local model), DigitalOcean (run the model on a GPU Droplet for a team runner).
Background: we built and measured this kind of gate in Gate Your Terraform Plans: Rules Decide, the Model Explains. To practise the plan workflow itself, try the Terraform terminal simulator.
5. A first responder for support tickets, for small hosting companies
The customer: a small hosting company or WordPress agency with a support inbox.
The problem: half the tickets say "my site is slow" or "my site is down", and each one starts with the same ten minutes of log reading before anyone can answer.
What it does: when a ticket arrives, plain code collects the facts for that customer's site: the 5xx rate and slowest URLs from the last 24 hours of access logs (add $request_time to the nginx log format, because the default format does not record it), PHP-FPM slow log entries (turn on slowlog and request_slowlog_timeout first), disk and inode usage, and recent deploys and plugin updates from your deploy tool. A local model drafts the reply and an internal note. A person edits and sends it. The tool never sends a reply on its own.
Why open matters: access logs contain your customers' visitors' IP addresses, which are personal data in many countries. Keeping logs and model on your own servers keeps that data where your contracts say it is. Your cost per ticket also does not depend on someone else's price list.
Week scope: one log format, four facts, one draft reply. Use your own sites' logs, or generate a sample log for the demo.
Your first user: anyone who answers a hosting support inbox. Ask them to time one ticket with the tool and one without.
Partner fits: Mastra (an agent with tools for each fact), Sentry Agent Tracing (show latency, tokens and cost per ticket, which is also your unit cost).
Background: we measured a similar pattern for CI logs in Explaining CI Failures Automatically with a GitHub Action. The biggest win there was throwing away most of the log before the model saw it.
6. A handover runbook from your shell history, for freelance sysadmins
The customer: a contractor at the end of a contract, or a small company whose only ops person is about to leave.
The problem: the knowledge is in shell history and in one person's head. The handover document is written in the last two days, from memory.
What it does: reads shell history, script logs or asciinema recordings. Set HISTTIMEFORMAT in bash now if you want timestamps; it does not add them to old history. A history file does not record which server it came from, so collect one file per host. Plain code finds secrets first with a scanner such as gitleaks, replaces them in the text, and shows you the result to check before the model sees it. Then it groups commands into tasks by host and time. A model turns each task into a runbook step and leaves a "Why?" line for the human to fill in. The model must not invent the reason for a command.
Why open matters: shell history is full of hostnames, IP addresses and secrets that people typed on the command line. It is the one file you should never paste into a hosted chat. This is also a good place to fine-tune: a small model trained on your own "session to runbook step" examples can beat a bigger general model on this narrow task.
Week scope: one week of your own history, ten runbook steps, one Markdown file.
Your first user: you. Then a contractor friend at the end of a contract.
Partner fits: Tinker (fine-tune a small model for this task and show the improvement over a baseline, which is exactly what its category asks for; Tinker is hosted, so train only on examples you have cleaned or written yourself), Gemma (the base model).
Background: our post You Cannot Rotate a Secret You Cannot Find counts how many copies of a credential end up on laptops, and shell history is one of them. To practise the commands, use the Linux terminal simulator.
A starter for idea 4
All six ideas use the same split: plain code finds the facts and applies the rules, and the model only writes the words. Here is that split for the Terraform plan explainer, with Ollama and Gemma 4. Run it in a Terraform directory after terraform init, with Ollama running:
set -euo pipefail
ollama pull gemma4:e4b
terraform plan -out=tfplan
# 1. The facts, from plain code: resource addresses and actions, no values
FACTS=$(terraform show -json tfplan | jq -c '{
changes: [(.resource_changes // [])[]
| select(.change.actions != ["no-op"])
| {address, action: (.change.actions | join("+"))}],
destroys: [(.resource_changes // [])[]
| select(.change.actions | index("delete"))
| .address]
}')
# 2. The rule, from plain code: anything that deletes needs a sign-off
RISK=$(jq -r 'if (.destroys | length) > 0 then "needs-sign-off" else "no-deletions" end' <<<"$FACTS")
# 3. The words, from a local model
jq -n --arg facts "$FACTS" --arg risk "$RISK" '{
model: "gemma4:e4b",
stream: false,
messages: [
{role: "system", content: "You explain Terraform changes to a client who is not an engineer. Use only the facts you are given. delete+create and create+delete both mean the resource is replaced. If a deleted or replaced resource can hold data, such as a database or a bucket, say that its data can be lost unless it is backed up first. Do not change the risk level."},
{role: "user", content: ("Risk: " + $risk + "\nChanges: " + $facts)}
],
format: {
type: "object",
properties: {
summary: {type: "string"},
questions_for_client: {type: "array", items: {type: "string"}}
},
required: ["summary", "questions_for_client"],
additionalProperties: false
}
}' | curl -fsS http://localhost:11434/api/chat -H 'Content-Type: application/json' -d @- \
| jq -e --arg risk "$RISK" '(.message.content | fromjson | {summary, questions_for_client})
+ {risk: $risk, tokens: .eval_count, seconds: (.total_duration / 1e9)}'
We ran steps 1 and 2 on a real plan from Terraform 1.15 that replaces one resource, deletes one, updates one and creates one. Step 1 gives the model this, and nothing else from the plan:
{
"changes": [
{"address": "terraform_data.cache", "action": "create"},
{"address": "terraform_data.database", "action": "delete+create"},
{"address": "terraform_data.old_bucket", "action": "delete"},
{"address": "terraform_data.web", "action": "update"}
],
"destroys": ["terraform_data.database", "terraform_data.old_bucket"]
}
Step 2 sets the risk to needs-sign-off. The model cannot change it: the last line keeps only the two text fields from the model's answer and adds the risk from plain code after them. The format field constrains the answer to that JSON shape, and the answer comes back as a JSON string in .message.content, which is why the last line parses it with fromjson.
This starter only catches deletes and replacements. An in-place update can be dangerous too, for example one that opens a firewall rule, so add your own rules before a client trusts it.
Work out your cost per job before you pick a price
The last line also prints tokens and seconds. Ollama returns eval_count (generated tokens), prompt_eval_count (input tokens) and total_duration (in nanoseconds) in its final response, so you can measure the model's part of one job without guessing. Run it on ten real inputs and write down:
- Seconds per job on the machine you would really use.
- Cost per hour of that machine. On your laptop that is close to zero; on a rented GPU server it is the hourly price.
- Cost per job = cost per hour / jobs per hour.
- Jobs per customer per month. A DMARC summary runs once a week. A support responder runs on every ticket.
That is the model cost only. A rented server also costs money while it waits for work, and your own support time is usually the biggest cost of all, so add both before you set a price.
Put these numbers in your post. A judge who reads "it costs us less than one cent per report, so we can charge five euros a month per domain" believes the business. A judge who reads "it is cheap" does not.
Check the license of every model you use before you charge for it, too. Open-weight models come with different terms, and some partner tools have free tiers for non-commercial use only.
How to fit it into one week
- Monday or Tuesday: find the customer before you write code. Message three people who have the problem. Ask what they do today and what it costs them in time or money. One reply is enough to start.
- Midweek: build the ugly version. One input, one output, from the command line.
- Friday: put it in front of your first user. Watch them use it. Ask "would you pay for this, and how much?" Write down the answer word for word.
- Saturday and Sunday: write. Writing has the most weight, and submissions close on Sunday night, Pacific time. Leave yourself at least three hours.
What to put in the write-up
- Who pays and why, in the customer's own words.
- Your cost per job and the price you would charge, with the numbers.
- Why open, concretely. "The billing export never leaves the customer's laptop" is stronger than "open source is important".
- Your first user: what they did, what they said, whether they would pay, and what they asked for next. The organisers ask for exactly this.
- What did not work: a model that answered "Yes" with no evidence, a parser that broke on one provider's export. Judges trust posts that show the hard parts.
- A demo: a link to the deployed project or a video demo is required, plus a link to the code. Screenshots and terminal recordings help, but they do not replace the video or the link.
- 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
Week 3 starts on Monday, October 19, with a new theme. We post DevOps project ideas for each theme on the day it launches. If you missed it, here are our ideas for Week 1: Touch Grass.
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 worth learning), our 7-day Hacktoberfest challenge gives you one small, reviewed PR a day.
Which boring ops job would you pay someone to take away? Tell us in the comments. Someone reading this week might build it.
Top comments (0)