DEV Community: Gavindu achintha

MailTriage: a local inbox desk a freelancer would pay for

Gavindu achintha — Sat, 17 Oct 2026 06:23:42 +0000

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

What I Built

MailTriage is a local triage desk for freelancers. You connect Gmail, the app sorts client mail by what actually needs you, and a local model drafts a reply in your voice. You edit it. Nothing is sent until you save it to Gmail Drafts yourself.

Categories: urgent, waiting on a client, invoice, new lead, low priority. Each message also gets a priority score, a one-line summary, and a suggested action.

Who would pay: a freelancer whose inbox is invoices, “just circling back”, real deadlines, and new leads — and who will not paste client names and rates into a hosted chatbot.

The problem: cloud copilots want the whole thread. MailTriage keeps inference on the laptop (Ollama + Gemma 3). Gmail tokens stay in a signed cookie. Postgres only stores writing-style examples and the last triage per message, not the inbox.

Gmail  --read only-->  MailTriage  --local Gemma-->  draft
                            |
                       Postgres
                  (style + last triage)

Demo

Code

Gavinduachintha / mailtriage

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

Next.js Documentation - learn about Next.js features and API.
Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more…

View on GitHub

How I Built It

Open-source AI is the core, not a plugin:

Local inference: Ollama on 127.0.0.1
Open-weight model: Gemma 3 (OLLAMA_MODEL=gemma3)
The model does the whole job: category, priority, summary, suggested action, and the draft. Style examples you save (past replies) are loaded from Postgres and sent with the prompt so the next draft sounds like you.

The rest of the stack is a desk around that call:

Next.js 16 — inbox list, retractable sidebar, draft panel, settings
Gmail API — read-only inbox, save to Drafts (never auto-send)
PostgreSQL + pg — no ORM. Tables are mailtriage_users, mailtriage_style_examples, mailtriage_analyses so they do not collide with an existing users table. Queries are plain SELECT / INSERT / UPDATE / DELETE. Saving an analysis is an update, then an insert if nothing matched.

The Next.js pool is one pg.Pool on globalThis so hot reload does not leak connections. If DATABASE_URL changes, the pool is rebuilt.

Why Does Open Innovation Matter?

A freelancer will not pay for a tool that uploads their clients to a hosted model. Rates, NDAs, and “can you invoice this week” do not belong in someone else’s cache.

A closed mail API would have been easier to demo (paste a key, ship a URL) and worse to sell. Open-weight Gemma on Ollama is what makes the side hustle honest:

Privacy — the thread is inferred on the same machine that already has the inbox
Cost — no per-token bill for “sorry for the delay,” so the product can be a one-time or cheap local tool
Control — swap the model with OLLAMA_MODEL instead of rebuilding around one vendor’s price and terms

The open pieces are why someone would pay this instead of pasting the email into ChatGPT.

My Agent Session

Building MailTriage: local Gemma triage, Postgres, Week 2 post

You

Analyze the UI. It looks like the usual LLM dashboard. Make it professional for freelancers, keep it consistent, no fancy gradients.

Agent

Replaced the indigo/serif LLM look with warm stone neutrals, a single muted teal accent, IBM Plex Sans/Mono wired correctly, and a calmer inbox/sidebar/draft panel. No gradients.

▸ search_replace app/globals.css palette + font-sans

Input

app/globals.css palette + font-sans

Output

Stone surfaces, teal primary, Geist mismatch fixed to Plex

You

Add a settings option and make the sidebar retractable.

Agent

Desktop sidebar collapses to an icon rail (saved on the device). Settings dialog covers theme, writing style, local model status, and Gmail disconnect.

▸ write components/sidebar.tsx + settings-dialog.tsx

Input

components/sidebar.tsx + settings-dialog.tsx

Output

Collapse toggle + Settings under Workspace

You

Add an avatar in the header. The application name is MailTriage.

Agent

Header shows initials from the Gmail address and a menu (settings, disconnect). Renamed InboxGuard to MailTriage in the UI, metadata, landing copy, and model prompt.

You

Add a database. Using Postgres. Keep it simple, no ORM.

Agent

Added pg Pool + raw SQL. Tables: users, style examples, analyses. Gmail tokens stay in the cookie. Inbox still comes from Gmail.

▸ write lib/db/pool.ts, lib/db/queries.ts, db/schema.sql

Input

lib/db/pool.ts, lib/db/queries.ts, db/schema.sql

Output

Parameterized queries, no Drizzle

You

Keep the db query simple. I need the full query including creating the tables.

Agent

Flattened to SELECT/INSERT/UPDATE/DELETE. Save path is UPDATE then INSERT. Gave the full CREATE TABLE script.

You

CREATE TABLE users skipped (already exists). style_examples failed: column email referenced in foreign key does not exist.

Agent

They were on postgres.public. An existing users table had no email column. Renamed tables to mailtriage_users, mailtriage_style_examples, mailtriage_analyses.

▸ write prefixed table names

Input

prefixed table names

Output

FK now references mailtriage_users(email)

You

password authentication failed for user postgres

Agent

A direct pg client connected. Next.js was still using a pool created with the old DATABASE_URL. Pool now rebuilds when the URL changes and prefers [REDACTED]. Restart the dev server after env changes.

▸ write lib/db/pool.ts recreate on URL change

Input

lib/db/pool.ts recreate on URL change

Output

Stale pool no longer keeps a bad password

You

Create the markdown file. Add aesthetics. This is for Hacktoberfest Week 2. Put it on DEV too. Here is the official submission template.

Agent

Wrote README.md for the Side Hustle pitch. Drafted a DEV post on the linked account with the Week 2 template, repo embed, and Best Use of Gemma. Left it unpublished for review.

▸ create_article title MailTriage Week 2 draft, published false

Input

title MailTriage Week 2 draft, published false

Output

Draft saved; edit_url handed to user

Build log from this session: UI pass, retractable sidebar and settings, MailTriage rename, Postgres without an ORM, the users table collision, and the stale connection-pool password bug.

Prize Categories

Best Use of Gemma — triage and drafts run on Gemma 3 through Ollama. No hosted LLM.

[Boost]

Gavindu achintha — Mon, 12 Oct 2026 13:20:03 +0000

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass Submission 🌿

Gavindu achintha

Oct 11

I built a fully offline nature field guide with Gemma 3

#devchallenge #hf26challenge

3 min read

I built a fully offline nature field guide with Gemma 3

Gavindu achintha — Sun, 11 Oct 2026 08:02:51 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Trailside is an on-device nature field guide. Point your camera at a plant, bird, insect, or fungus — or upload a photo you already took — and get field notes in seconds. No signal, no cloud, no account. Everything runs locally with a small vision model, so it works on the trail, in the woods, or anywhere the cell bars disappear.

You can use it from your laptop or phone: open the app in the browser, connect your device camera to snap something in the moment, or drop in a local image from your gallery. Optionally add a quick note of what you already know, and Trailside returns structured field notes. Save the ones that matter to a personal LogBook so the memory stays with the place, not the feed.

It is built for people who want to look closer at the living world instead of scrolling past it: hikers, gardeners, kids on weekend walks, anyone who has ever wondered “what is that?” and wished for a quiet answer in their pocket.

The goal is simple: get people off the screen and back into the world — with just enough help to notice more of what is already around them.

Demo

Video Demo

Code

https://github.com/Gavinduachintha/Trailside

How I Built It

Trailside is built around Ollama running the open-weight Gemma 3 vision model (gemma3:latest) entirely on-device. There is no cloud API and no remote inference — the model lives on the user’s machine, so identification works offline on the trail.

The app is a Streamlit front end that handles camera capture or file upload, lightly processes the image with Pillow (EXIF orientation, resize, JPEG encode), then streams the photo and an optional user hint into Ollama’s chat API. A system prompt and a small prompt builder shape the model’s reply into readable field notes. Responses are streamed token-by-token into a journal-style panel so the experience feels immediate.

Saved sightings (image + notes + optional hint) are stored in a local database via a thin config.db layer, and the LogBook view lets users browse, open, and delete entries. The whole stack — UI, local model, and storage — stays on the device so the tool remains useful where signal is weak or absent.

Why Does Open Innovation Matter?

Open innovation is what makes Trailside possible as a real field tool instead of another phone feature that dies when the bars disappear.

Because the model is open-weight and runs locally through Ollama, every photo stays on the device. There is no upload, no account, no usage quota, and no dependency on a remote API that could change price, rate limits, or terms overnight. That privacy and reliability matter when you are identifying something in the woods — not because the data is sensitive in a corporate sense, but because the tool should work where you actually need it: offline, on a trail, with whatever hardware you already have.

A closed vision API would have forced a constant network connection, sent images off-device, and tied the project to someone else’s pricing and availability. Open models and local inference remove that gate. They let a small, single-purpose app treat the model as a quiet companion on the path rather than a service you rent by the request.

Prize Categories

Best Use of Gemma — Trailside is built around Gemma 3 running locally through Ollama. The model does the full multimodal identification: it receives the photo (and optional user hint), streams the field notes, and never leaves the device. No other AI or partner runtime is involved.

My friends refuse to write Dockerfiles, so I built an AI that does it for them. You're welcome, lazy people. 🐳

Gavindu achintha — Sun, 04 Oct 2026 07:01:37 +0000

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

What I Built

I built DockForge, an AI-powered Docker engineer that turns a software repository into a working Docker setup.

I built it for a friend who often works on projects that run perfectly on their machine but become painful to containerize.

Instead of manually figuring out the runtime, dependencies, package manager, ports, build commands, system packages, and startup configuration, DockForge analyzes the repository and generates a Docker setup tailored to the project.

The goal isn't just to generate a Dockerfile that looks correct.

DockForge is designed around a generate → build → verify → fix workflow.

It can:

Analyze the repository structure and identify the technology stack
Detect dependencies and package managers
Determine likely build and start commands
Generate a Dockerfile

In other words:

Repository → Analyze → AI → Dockerfile → Build

Demo

dockforge-chi.vercel.app

The demo shows DockForge taking an existing repository and automatically producing a Docker configuration instead of requiring the developer to manually write one from scratch.

Code

Gavinduachintha / Dockforge

Ai powered docker file generating companion

🐳 DockForge

AI-Powered Dockerfile Generator for Modern Applications

Analyze any GitHub repository and get an optimized, production-ready Dockerfile in seconds.

🚀 Quick Start • 📖 Setup Guide • 🎮 Demo • 🛠️ Features • 🤝 Contributing

🎯 What is DockForge?

DockForge is an intelligent tool that analyzes your GitHub repository and automatically generates production-ready Dockerfiles tailored to your project's specific needs. No more copy-pasting generic Dockerfiles or spending hours optimizing Docker configurations!

Why DockForge?

⚡ Fast

Generate Dockerfiles in seconds, not hours

🧠 Smart

AI-powered analysis and optimization

🎯 Accurate

Framework and dependency detection

✨ Modern

Best practices and security built-in

🚀 Quick Start

Get DockForge running in 5 minutes:

# 1️⃣ Clone the repository
git clone https://github.com/yourusername/dockforge.git
cd dockforge
# 2️⃣ Install dependencies
npm install

# 3️⃣ Set up environment variables
cp .env.example .env
# Add your OpenRouter API key to .env

# 4️⃣ Start the development server

…

View on GitHub

DockForge is built as an open-source project, so the implementation can be inspected, modified, and extended by other developers.

How I Built It

I built the whole application with Next.js and used the OpenRouter API to connect it with an LLM.

For the AI side, I'm using Qwen3.8-27B whick is free. DockForge takes the project information and asks the model to figure out what kind of Docker setup the project needs and generate the Dockerfile.

I wanted to keep the idea simple: instead of spending time figuring out how to Dockerize a project manually, you can give it to DockForge and let the AI handle the first draft for you.

OpenRouter also made it really easy to experiment with different models without having to change the whole application.

The process is roughly:

Repository
    ↓
Repository Analysis
    ↓
Project Detection
    ↓
AI Planning
    ↓
Dockerfile Generation
    ↓
Docker Build
    ↓
Build Errors / Verification
    ↓
AI Fixes
    ↓
Working Container

The AI is responsible for reasoning about the project and generating the configuration, while Docker provides the real-world feedback.

This distinction is important.

A language model can generate a Dockerfile that sounds right while still being completely broken. By actually attempting to build the image, DockForge can use Docker's output as feedback and iterate on the configuration.

For the AI layer, I used open-weight models through OpenRouter, allowing the underlying model to be replaced without redesigning the application around a single proprietary AI provider.

This also means the architecture can evolve toward local inference and self-hosted models instead of being permanently tied to one closed AI API.

Why Does Open Innovation Matter?

Dockerization is one of those problems where there are many different valid solutions depending on the project.

A Python application, a Node.js application, a Go service, and a project with native system dependencies all require different decisions.

Open AI models make it possible to build tools around that reasoning without treating a single proprietary AI provider as the foundation of the product.

For DockForge, open innovation matters in a few important ways.

Model freedom

The application isn't fundamentally tied to one model.

As better open-weight coding models become available, DockForge can adopt them without rebuilding the entire product around a proprietary API.

Local and self-hosted possibilities

The same architecture can evolve toward local inference and self-hosted models.

That opens the door to using DockForge in environments where source code cannot or should not be sent to an external AI provider.

Build an AI email summarizer with event planning

Gavindu achintha — Sat, 13 Sep 2025 15:56:16 +0000

Built a full-stack email dashboard with Gmail API integration and Google Calendar event planning using React, Node.js,OpenRouter and Kiro AI to accelerate development for the Code with Kiro hackathon.