DEV Community: Subhranshu Dash

Paydirt: How I Built an Open-Weight AI Agent to Turn GitHub Bounties into a Real Side Hustle

Subhranshu Dash — Sat, 17 Oct 2026 17:11:43 +0000

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

What I Built :
Every open-source contributor knows the sting of bounty ghosting: you spend two evenings fixing a thorny bug on a funded GitHub issue only to find the maintainer hasn't logged in since August, another contributor opened an unreviewed PR three weeks prior, or the bounty platform escrow terms are predatory. Over 60% of open-source bounties never pay out, turning developer side-hustle time into uncompensated labor.

Paydirt turns open-source bounty hunting from a lottery into an evidence-based side hustle. It is an open-weight, privacy-firs
AI agent that:

Discovers Funded Issues: Scrapes and normalizes bounties across GitHub issues (Algora, issue tags, corporate sponsorship tiers).
Predicts Real Payout Probability ($P(\text{payout})$): Uses Prior Labs' TabPFN Bayesian tabular foundation model to score whether a funded issue will actually merge and pay out based on repo velocity, maintainer response intervals, review churn, and bounty size.
Calculates Expected Value: Ranks opportunities by and hourly earning efficiency, steering contributors toward high-conviction wins instead of vanity sums.
Local Skill Matching via Gemma: Embeds your local git commit history and GitHub profile via open-weight Gemma 3 + EmbeddingGemma running entirely on your machine through Ollama. Your code, habits, and private repos never leak to third-party cloud APIs.
Durable Lifecycle Tracking via Temporal: Manages the entire lifecycle—from claiming intent and plan generation to PR submission and bounty release—with durable timers and webhook signals.
Built-in Safety & Dry-Run Guarantees: Strict safety guards prevent accidental spam or premature claims; all external GitHub mutations require manual user confirmation. Who would pay for it? Freelance developers, student contributors, and independent OSS maintainers looking to monetize 10–20 hours a week without burning time on ghosted issues. A monthly subscription or 2% success fee on settled payouts provides a clear ROI in just one saved weekend.

Demo :

Platform preview : https://paydirt-iota.vercel.app/

*Code *:

Repository: https://github.com/subhranshudash13-dotcom/Paydirt
Monorepo Structure:
packages/shared: Shared types, bounty ranking algorithms, and schemas.
apps/api: Fastify backend, TimescaleDB/Tiger Data store, and live hydrate feed.
apps/worker: Temporal workflows for durable bounty lifecycle management.
apps/web: React 18, TypeScript, Tailwind CSS, Vite with responsive neo-brutalist UI.
services/predictor: TabPFN Python Bayesian scoring sidecar.

How I Built It :
Paydirt was architected around open innovation, modular workflows, and local-first execution:

Open-Weight AI & Local Inference Google Gemma 3 (gemma3:4b) & embeddinggemma: Orchestrated locally via Ollama. Contributors' GitHub profile bios, repositories, and past pull requests are converted into dense vector embeddings locally. When viewing an issue, similarity between developer skills and issue requirements is scored on-device with zero cloud latency and total privacy. TabPFN (Prior Labs): Rather than hallucinating a payout score through an LLM, we utilize TabPFN—a foundation model specifically trained on tabular data. It computes calibrated probabilities $P(\text{payout} = 1)$ using 8 tabular features (maintainer response frequency, open PR count, repo activity age, issue description length, and historical bounty settlements).
Temporal Durable Workflows
Bounty hunting is an asynchronous, multi-week endeavor. Paydirt uses Temporal (@temporalio/workflow and @temporalio/activity) to track claims. Workflows pause for review signals, automatically trigger reminder check-ins before bounties expire, and verify when PRs merge—all surviving process restarts.
TimescaleDB / Tiger Data with pgvector
PostgreSQL equipped with timescaledb and pgvector stores time-series telemetry on issue churn (tracking how maintainer response latency drifts over time) and runs vector cosine searches for skill-to-bounty matching. In development, a memory fallback allows instant out-of-the-box prototyping.
Sentry Error Tracing & Telemetry
Configured across Fastify and Temporal workers (@sentry/node), ensuring failed API scraping pipelines, unparsed issue formats, or network timeouts are captured with full stack traces and contextual tags.

Why Does Open Innovation Matter?
True Privacy for Developer IP: Closed AI APIs (OpenAI, Anthropic) require transmitting code, private git histories, and developer profiles to remote corporate servers. By using open-weight models like Gemma 3 running locally on Ollama, developers never leak uncommitted scratchpad notes or proprietary codebases just to get AI assistance.
Reproducible, Non-Degrading Models: Proprietary models silently update or suffer regression across versions. Open models allow us to pin exact weights (gemma3:4b, TabPFN checkpoints) so payout predictions and scoring metrics remain consistent and verifiable.
Zero API Cost for Students & Indie Hackers: Contributors working on bounties should not have to spend $20/month in API credits just to find out which bounties are worth their time. Open weights run on hardware developers already own.

Kaagaz: I built a private life-admin companion for my parents

Subhranshu Dash — Mon, 05 Oct 2026 03:47:57 +0000

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

What I Built

My parents are actually pretty good at keeping important documents.

Electricity bills, warranties, receipts, notices, insurance papers — they usually have them somewhere. The problem isn't losing the documents.

It's remembering what each document means and what needs to happen next.

A bill arrives and it needs to be paid before a certain date. A warranty is kept safely, but nobody remembers when it expires. A new electricity bill looks higher than the previous one, but comparing the two means opening both documents and doing the math. A notice gets saved, and a few weeks later the question becomes: "Did we already take care of this?"

I found myself helping with these little things quite often.

None of them is difficult. But when you're managing all the paperwork of a household, there are a lot of them.

So I built Kaagaz for my parents.

Kaagaz takes the documents they already have and turns them into something more useful: the important facts, what changed, what is coming up, and what actually needs attention.

Instead of:

"Here's another PDF."

Kaagaz tries to answer:

"What do I need to know, remember, or do because of this document?"

For example, an electricity bill can become:

₹2,450 due October 12
and, if there is a previous bill:
₹379 higher than the previous bill.
The idea is simple: turn paperwork into action.

Demo

[

]

[Live preview : https://kaagaz-sand.vercel.app/]

Code

[https://github.com/subhranshudash13-dotcom/Kaagaz]

Kaagaz is designed as a local-first application, so the core experience can run on the user's own machine instead of requiring their household documents to be uploaded to a cloud AI service.

How I Built It

The basic flow is:

01 Upload Document
        ↓
02 Read & Classify
        ↓
03 Extract Facts with Gemma
        ↓
04 Validate the Information
        ↓
05 Let the User Review It
        ↓
06 Save Only After Confirmation
        ↓
07 Turn Facts into Actions

The interesting part is that I didn't want the AI to make all the decisions.
Gemma is responsible for understanding the messy part of a document — figuring out whether something is a bill, warranty or notice and extracting the information that matters.
After that, normal application code takes over.
If the current electricity bill is ₹2,450 and the previous one was ₹2,071, Kaagaz doesn't ask the model how much it increased. It calculates the difference itself: ₹379, or 18.3%.
The same applies to deadlines and actions. If a bill is due in three days, deterministic rules decide that it needs attention. The model isn't responsible for deciding whether a date has passed.
That separation became one of the main ideas behind Kaagaz:

AI understands the document. Code handles the certainty. The person stays in control.

I also didn't want extracted information to silently become trusted data.

When Kaagaz reads a document, the result is provisional. The user sees what was extracted and can correct the amount, date, category or other fields before confirming it.

Only then does it enter the document vault and start generating actions.

That gives the flow a simple safety boundary:

AI reads
   ↓
AI proposes
   ↓
Person checks
   ↓
Person confirms
   ↓
Kaagaz remembers

Once the information is confirmed, Kaagaz can do more with it.
Recurring bills can be compared with previous documents. Deadlines can become actions. Calendar events can be generated. And Ask Kaagaz can answer questions using the confirmed information rather than making up an answer from scratch.

For example:

"What do we need to take care of this week?"
or:
"Why was the electricity bill higher this month?"
or:

"When does this warranty expire?"
The answers can be traced back to the information that was actually confirmed from the documents.

The stack

The frontend is React, TypeScript and Vite.

The backend is Python with FastAPI, Pydantic and SQLAlchemy, with SQLite keeping the core data local.

For document understanding, Kaagaz uses OCR together with Gemma running locally through Ollama.

I also use TabPFN for the historical-data side of the application. Once several utility bills have been confirmed, TabPFN can look at that structured history for forecasting and anomaly/pattern detection.

The important distinction is that the forecast is treated as a prediction. Concrete things such as "this bill increased by ₹379" still come from deterministic calculations.

Why Does Open Innovation Matter?

The documents Kaagaz deals with are exactly the kind of information I wouldn't want to casually send to another company's server.
An electricity bill can contain an address. An insurance document can contain personal information. Government notices can contain sensitive details.
The easiest implementation would have been to upload everything to a closed AI API.
Instead, I wanted my parents to be able to run the AI on their own computer.

Kaagaz uses Gemma through Ollama, so the document-understanding part can happen locally. There is no mandatory account, no mandatory cloud AI service and no per-document API cost in the local-first setup.
That changes the product quite a bit.

Privacy isn't something I have to promise after sending the documents somewhere else. The architecture itself can keep them on the machine.
It also gives me control over the AI layer. I can change the prompt, validate the model's output, experiment with different Gemma models and change the model without rebuilding the entire application around a proprietary API.
For this particular project, open innovation made the application more appropriate for the person I built it for.
My parents don't need to know which model is running.
They just need to know that when they give Kaagaz a bill, their document stays under their control and the answer they get is actually useful.

What My Parents Need From It

The most important thing I learned while building Kaagaz is that my parents don't really need an "AI document management platform."

They need something much simpler.

They need to know:

What needs my attention?

They don't want to inspect extraction confidence scores or understand an LLM pipeline.
They want to open the app and see that the electricity bill is due soon.
They want to know that this month's bill is higher than last month's.
They want to find the warranty they were looking for without searching through folders.
And if they ask a question, they want an answer based on the documents they actually have.
That changed the way I designed the product.
The AI is underneath.
The useful information is what stays on top.

What I Learned :

The biggest lesson for me was that an AI application doesn't have to make the AI responsible for everything.
In fact, for something involving personal documents, I think it is better when it doesn't.
Gemma is very useful for understanding a document because documents are messy and don't always follow the same structure.
But once the information is extracted, there are many things that should simply be handled by software.

Dates should be calculated by code.

Amounts should be compared by code.

Deadlines should be determined by rules.

And the person who owns the document should decide whether the extracted information is correct.

That ended up making Kaagaz feel much more trustworthy than the original idea of simply sending a document to an AI and asking it what to do.

What's Next

I would like to take Kaagaz further with camera-based document capture, recurring-document detection, email or WhatsApp ingestion, notifications and eventually a shared household mode where family members can help manage documents together.

But the original idea would stay the same.

My parents already have enough things to remember.

I don't want Kaagaz to become another thing they have to manage.

I want it to quietly take one small piece of that mental load away.

Prize Categories

Best Use of Gemma

Kaagaz uses Gemma as its local document-understanding model through Ollama. Gemma handles document classification and structured information extraction, while the application validates its output and keeps the user in the confirmation loop before anything becomes trusted data.

Best Use of TabPFN

Kaagaz uses TabPFN on confirmed historical utility-bill data to explore forecasting and anomaly/pattern detection. Concrete bill-to-bill changes remain deterministic, while TabPFN is used for the predictive side of the experience.

And hopefully, a little less for my parents to remember. 🤝