DEV Community: Tushar Khadde

🦥 DrawBoard: Letting an Open-Weight Agent Do the Drawing So You Don't Have To

Tushar Khadde — Sat, 24 Oct 2026 17:43:14 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

DrawBoard is a real-time collaborative whiteboard — sketch, diagram, and think together in the browser, with live shape sync, room-based access control, and in-board chat.

But the laziness story runs on two levels.

For users: DrawBoard rewards the lazy visitor. You open the /canvas/guest page and you're drawing — no signup, no email, no onboarding wizard. One share link and anyone can join your board. When you're done, export the whole thing as PNG or SVG instead of screenshotting your sketch in four torn pieces. Keyboard shortcuts for every tool (V for select, P for pencil, Ctrl+K for the command palette) mean your hands never leave home row.

For me: the honest confession is that the sloth was the developer. I wanted a collaborative whiteboard for my own project discussions — Excalidraw-style, but the kind I fully understand because I built it. Setting aside weekend after weekend to hand-write a canvas engine, a WebSocket sync layer, and an auth flow across three services was exactly the task I kept putting off. So I didn't do it myself. An open-source AI agent did the heavy lifting, reviewed every plan with me, and I shipped the whole thing in the challenge window instead of someday/Maybe Land. Every file in this repo started as a conversation with an agent running an open-weight model.

Demo

▶️ Video demo: Watch DrawBoard in action (Google Drive)

drawrboard-1.mp4 - Google Drive

drive.google.com

🌐 Live app: drawboard-peach.vercel.app

The guest board at /canvas/guest is the fastest way in — no account needed. Create a room as a signed-in user, share the link, and watch shapes sync in real time.

Code

Tusharkhadde / draw-board

🎨 Drawboard

A real-time collaborative whiteboard. Sketch, diagram, and think together — right in the browser.

🌐 Live demo: drawboard-peach.vercel.app 📦 Repository: github.com/Tusharkhadde/Excalidraw

Overview

Drawboard is a collaborative whiteboard built as a pnpm + Turborepo monorepo with three services:

Next.js frontend — landing page, auth, workspace dashboard, and the canvas board
Express HTTP API — auth, rooms, room access requests, chat history
WebSocket server — live drawing sync + in-room chat

Data is stored in PostgreSQL via Prisma. You can draw as a guest (no account), or sign up to create shared rooms, request/approve access, chat while drawing, and export the board.

Tech stack

Layer	Technology
Monorepo	Turborepo + pnpm workspaces
Frontend	Next.js 15 (App Router), React 19, TypeScript
UI	Tailwind CSS, shadcn/ui (Radix), Lucide, sonner
Canvas	Custom HTML5 Canvas

…

View on GitHub

It's a pnpm + Turborepo monorepo with three deployable services:

Service	What it does
`drawboard-frontend`	Next.js 15 / React 19 — landing, auth, dashboard, and the canvas board (`/canvas/[roomId]`)
`http-backend`	Express REST API — auth (email + Google OAuth), rooms, access requests, chat history
`ws-backend`	`ws` WebSocket server — live draw / update / erase / sync / clear / chat messages

Plus shared packages: @repo/db (Prisma + PostgreSQL), @repo/common (Zod schemas for shapes and auth payloads), @repo/ui, @repo/backend-common (JWT helpers). One command — pnpm start:unix — frees ports 3000/3001/8080 and boots all three services together. There's no token in the codebase you can't audit and no behavior you can't change.

How I Built It

The open-source AI is in the process as much as the product: I built DrawBoard entirely inside OpenCode, an open-source agent harness, running GLM, an open-weight model. No paid API key, no proprietary assistant in the loop — the same agent harness pattern anyone can clone from a public repo and run today, pointed at a model whose weights are published.

How that actually played out across the build:

The canvas engine — a custom HTML5 Canvas layer, not a giant dependency. I went into it knowing the real-time sync protocol decisions matter more than the drawing code, and the community thread I leaned on here was @harshattray's "Frontend System Design: Designing a Collaborative Whiteboard", which walks from blank page to production architecture — I'd been priced by my own past attempts at hand-rolling this; reading someone else's take made it concrete.
The realtime layer — the agent and I settled on a plain ws server with explicit JSON message types (join_room, draw, update, erase, sync, clear, chat) rather than a framework. The tradeoff discussion borrowed from @kalevski's "Building Real-Time Apps in Node.js with Rivalis: WebSockets, Rooms, Actors, and a Binary Wire" — explicit message types keep the server auditable in an afternoon, which mattered because this whole codebase's selling point is that you can read it.
Realtime architecture posture — @iammuhammadarslan's "Building Scalable Real-Time Applications with Node.js, Socket.io, and React" was a useful sanity-check on Socket.io vs raw ws for this scale; we chose the thinner dependency.
Working with the agent — the workflow that stuck: I asked it to read the code and verify its claims against the actual repo rather than repeat conventions from memory. That discipline bit already once: this week the agent found the README had been saved with broken encoding (mojibake diagrams + null bytes), documented a start script that didn't exist, and was missing an entire room access-request flow from the docs — rewrite it against the real schema (User → RoomAccess / AccessRequest → Chat in Prisma) instead of trusting my description of it.

Everything ships with a permissive license, a plain-language README, and an .env.example — so a reader can clone, set two variables, and have the full three-service stack running locally on Node 18 and Postgres.

Why Does Open Innovation Matter?

Three concrete reasons it made THIS build possible, not just a nicer flavor of it:

Zero marginal cost to iterate. An open-weight model cost me nothing per token. I could burn through dozens of agentic sessions — regenerate the tool-dock UI, redo the sync message schema, restructure the monorepo — with no pricing anxiety. A metered closed API quietly pushes you toward fewer attempts, and fewer attempts means a worse product. With GLM's open weights I never once thought "I shouldn't ask that again."
The process is inspectable, so the product is trustworthy. Because the harness is open source and the model is open-weight, I can see how the agent works, pin its behavior, and hold it to what it writes. When I tell readers "the codebase has no black box in it," I can say the same about the tooling that produced it. A closed API is a black box inside a black box.
The stack stays fully open, end to end. Next.js, React, Tailwind, shadcn/ui, Express, ws, Prisma, PostgreSQL, Turborepo — every layer is something a 16-year-old in a small town with no cloud budget can clone and run. That's who open innovation is for: the person this challenge's sloth would want behind the keyboard. Nobody needs my permission to fork DrawBoard, self-host it behind their own firewall, and delete the parts they don't want.

My Agent Session

The full working session — from diagnosing the corrupted README, to challenging the agent's stale claims against the real Prisma schema and Express routes, to preparing this submission — is embedded below. It also shows the discipline I'd recommend to anyone vibe-building with agents: make it re-read the repo instead of quoting its memory.

DrawBoard: reviving a corrupted README and shipping a Hacktoberfest entry with an open-source agent

You

make readme file better

Agent

Let me check the README first to see what needs improving.

▸ read README.md

Input

README.md

Output

Cannot read binary file: README.md

Agent

Interesting — the README can't even be read as text. Let me inspect the raw bytes.

▸ shell Get-Content README.md -Raw

Input

$ Get-Content README.md -Raw

Output

# Drawboard ... mojibake box-drawing diagrams ... trailing line: '#' d r a w - b o a r d' with null bytes

Agent

Found it: the file was saved with broken encoding — mojibake in the ASCII diagrams and null bytes at the end. I also need to verify its claims before rewriting.

▸ shell package.json / .env.example / prisma schema / http routes / ws message types

Input

$ package.json / .env.example / prisma schema / http routes / ws message types

Output

pnpm start -> scripts/start.ps1 (missing); routes: /signup /signin /auth/google /me /room /rooms /room/:key /rooms/:key/access-requests +approve /chats/:key /users/search; models: User Room RoomAccess AccessRequest Chat; ws types: join_room leave_room draw update erase sync clear chat

Agent

The README is outdated too: it documents a Windows start.ps1 flow that doesn't exist, a legacy web app that was removed, and never mentions the room access-request flow. Rewriting it clean UTF-8 with corrected endpoints and scripts.

▸ write README.md

Input

README.md

Output

wrote clean, verified README with architecture diagram, accurate API table, correct pnpm start:unix instructions

You

just make more readable readme files

Agent

Done — replaced the sprawling mojibake diagrams with one compact diagram and clean tables, and corrected all the stale claims.

You

[Hacktoberfest Week 3 template] this is the submission template give me post i have no teammates

Agent

Fetching the challenge's full_details first.

▸ get_challenges page 1

Input

page 1

Output

Week 3 'Slow and Steady' (id 81): open-source AI that rewards laziness; theme honors Sloth Day; required tag #hf26challenge; due Oct 25 11:59 PM PDT; judging weighted toward writing quality; 20 partner prize categories

Agent

Checking what the dev.to community has already written about collaborative whiteboards so the post joins the ongoing thread.

▸ search_dev_to_semantic real-time collaborative whiteboard WebSockets canvas

Input

real-time collaborative whiteboard WebSockets canvas

Output

10 posts: system design walkthroughs, React+Go live diagram canvas, 60fps live cursors, Socket.io realtime architecture

Agent

Confirmed with the author: project was built with the OpenCode agent harness on the open-weight GLM model; no partner tech used, so no prize categories; session will be embedded. Drafting the submission to DEV drafts.

You

yes — save & embed the session, and stage the post as a draft

The Lazy Payoff

Real numbers, no exaggeration:

Ship time: this monorepo — a canvas engine, a REST API, a WebSocket sync server, auth with Google OAuth, room ACLs with approve/reject logic, chat, PNG/SVG export — went from "someday" idea running in my head to a deployed app with a live demo, inside one challenge window. Hand-rolling that used to translate into multiple abandoned weekends of mine.
Setup time: clone + two env vars + pnpm start:unix and all three services are up with correct ports. Before this repo had a decent README, an agent literally diagnosing a corrupted README with null bytes was the debugging tax I was still paying this week — that friction is now zero for the next person.
Guest path: zero signup for a first draw. Share-link join with owner-approved access requests. If someone just wants to sketch with a friend for five minutes, the entire cost is opening a URL.

The sloth won this week, and it won honestly: the open agent did the work, and I stayed steady while it did it.

MenuPage: Helping Small Restaurants Go Digital with AI 🍽️

Tushar Khadde — Sun, 18 Oct 2026 06:18:09 +0000

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

🍽️ MenuPage — A Digital Menu Platform for Small Restaurants

What I Built

I built MenuPage, a digital menu platform designed to help small restaurants, cafés, and food stalls establish an online presence and simplify their ordering process.

Many small food businesses still rely on printed menus and manual order management. Updating menus, sharing prices, and handling customer orders can become unnecessarily complicated.

MenuPage aims to make these tasks easier by bringing essential restaurant tools together in one place.

With MenuPage, restaurant owners can:

📱 Create digital menus that customers can access through QR codes.
🍔 Manage dishes, prices, and menu availability.
📲 Simplify ordering through WhatsApp.
🪑 Generate QR codes for individual restaurant tables.
📊 Manage orders through a restaurant dashboard.
💳 Support direct UPI payments.

Who would pay for it?

Independent restaurants, cafés, food stalls, and small restaurant chains that want a digital presence without the complexity of building their own website or depending entirely on third-party food delivery platforms.

My goal is to make digital restaurant tools more accessible and affordable for small businesses.

Demo

🚀 Live Website: https://menupage-topaz.vercel.app/

🎥 Video Demo: Watch the demo

The demo showcases the product and its approach to making restaurant menus and ordering more accessible.

Code

💻 GitHub Repository: Github

I'm building MenuPage as a practical product focused on real business needs, rather than just another portfolio project.

How I Built It

I built MenuPage as a web application with a customer-facing digital menu and restaurant management workflows.

The core idea is to connect menu management, QR-based access, customer ordering, and restaurant operations in one experience.

I'm exploring how open-source AI can make these workflows even more useful, particularly for:

🌐 Translating menus into multiple languages.
📸 Extracting dish names and prices from menu photos.
📈 Helping restaurants understand demand and plan food preparation.

These are areas where open-weight AI models could help reduce repetitive work and make useful technology more accessible to small businesses.

[Update this section with the exact AI models, frameworks, and inference provider used in the submitted version.]

Why Does Open Innovation Matter?

I believe small businesses should be able to benefit from AI without being locked into expensive proprietary services.

Open-weight models give developers the flexibility to experiment, compare approaches, customize workflows, and choose inference options that suit their budgets.

For MenuPage, open innovation creates opportunities to make multilingual menus and menu digitization more accessible to restaurants that may not have the resources to invest in custom software.

It also allows other developers to contribute, improve the implementation, and build new features on top of existing work.

The bigger idea is simple: AI should solve practical problems for everyday businesses, not just power impressive demos.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

🌿 Side Quest: An Open-Source AI Agent That Turns Screen Time into Real-World Adventures

Tushar Khadde — Sun, 11 Oct 2026 02:27:05 +0000

🌿 Side Quest: An Open-Source AI Agent That Gets You Off Your Screen

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

What I Built

We spend hours staring at screens, often forgetting to step outside, take a walk, or notice the world around us.

Side Quest is an open-source AI-powered outdoor companion that turns excessive screen time into small real-world adventures.

Instead of simply telling you to take a break, Side Quest creates a personalized 20-minute quest based on your local weather, sunset time, and nearby green spaces.

🌱 What it does:

Detects screen time: Tracks activity inside the PWA, with an optional lightweight desktop watcher for system-wide activity.
Generates outdoor quests: Uses open-weight AI models to suggest simple activities, like finding three different red leaves or exploring a nearby park.
Adapts to conditions: Checks weather, temperature, rain, storms, and sunset before suggesting a quest.
Gets you away from the screen: Switches to a dark, voice-friendly interface so you can complete your quest without constantly looking at your phone.
Verifies your adventure: Lets you submit a proof photo for AI-assisted verification and earn a stamp.
Keeps your memories local: Stores your quest history, photos, and statistics in your browser.

When outdoor conditions aren't suitable, Side Quest suggests a safer indoor-adjacent alternative, such as a balcony or covered area.

The goal is simple: less scrolling, more exploring.

Demo

🎥 Watch the Demo: Side Quest — Video Demo

🌐 GitHub Repository: Tusharkhadde/side-quest

💻 GitHub Repository: Tusharkhadde/side-quest

The project is open source under the MIT License. You can run it locally, experiment with different open-weight models, or self-host the inference layer.

How I Built It

Side Quest is built with Next.js, TypeScript, browser APIs, and an AI agent pipeline designed to work with multiple model providers.

The open-source AI stack

Gemma 4 26B A4B: The default model for generating quests and checking proof photos through the Gemini API.
Gemma 4 31B: A text-generation fallback through DigitalOcean's serverless inference.
NVIDIA Nemotron Nano 12B v2 VL: An open-weight vision-language model for photo verification through DigitalOcean.
Ollama: An optional route for running compatible models locally.
TabPFN: An optional experiment that predicts when a user is most likely to accept a quest based on their exported journal data.

How the agent works

Gather local context, including approximate location, weather, sunset time, and nearby parks or paths.
Apply code-based safety rules to determine which types of quests are appropriate.
Ask the selected open-weight model to generate a structured quest with clear steps and a safety note.
Validate the response and retry or switch providers if generation fails.
Let the user complete the quest, submit a photo if they choose, and earn a stamp.

The application uses Open-Meteo for weather information and OpenStreetMap data for nearby places.

It also includes a lightweight desktop watcher that detects extended periods of computer activity without sending activity data to a remote server.

Why Does Open Innovation Matter?

For a project focused on personal habits and privacy, having control over the AI stack matters.

Open-weight models make it possible to experiment with different inference providers, change models without rebuilding the application, and eventually run inference entirely on local hardware.

With Side Quest:

No single-provider lock-in: The provider chain can switch between hosted inference, compatible endpoints, Ollama, and a deterministic demo fallback.
More control over privacy: Location processing happens on the device, and self-hosted inference can keep model inputs on your own hardware.
Transparent experimentation: Developers can inspect the prompts, validation schemas, provider integrations, and safety logic.
Room to improve: Quest completion history can support future experiments with personalization and fine-tuning.

One important distinction: open weights don't automatically make hosted inference private. When a hosted provider is used, some information is sent to that provider. Side Quest documents these data flows and provides configuration options for developers who want more control.

Open innovation makes this project adaptable, inspectable, and easier for the community to build upon.

My Agent Session

The agent pipeline, provider fallback logic, and quest-generation implementation are available in the repository.

Explore the implementation: Side Quest on GitHub

Prize Categories

This project is submitted for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

Additional partner prize categories should be listed here only if Side Quest meets their specific eligibility requirements.

Built with open-source AI, a little curiosity, and the belief that the best quest sometimes starts by putting your phone down. 🌿

CI Watchdog — The Autonomous CI Minutes & Spend Sentinel with Open AI Failure Triage

Tushar Khadde — Mon, 05 Oct 2026 03:38:55 +0000

CI Watchdog

An autonomous GitHub App and SaaS platform that stops wasted CI spend before it hits your invoice, and automatically diagnoses broken builds using open-weight AI.

What I Built

Every developer has that one friend or team lead who dreads the 20th of the month: the day GitHub sends the notification:

"You have used 100% of your included GitHub Actions minutes."

I built CI Watchdog for my friend and engineering teammate, who was constantly battling ballooning CI bills and jammed pipeline queues on open-source and startup projects.

The problems:

Developers push 4 quick commits to a PR, and GitHub blindly spawns 4 redundant 15-minute test suites in parallel on expensive runners (Ubuntu, macOS, Windows).
When a build fails after 20 minutes, developers have to dig through 30,000 lines of terminal logs just to discover a blocked database container port or a missing env variable.

The solution:

Autonomous Waste Prevention: Detects and cancels superseded runs, runaway jobs exceeding historical p95 execution baselines, and PR workflows left running on closed branches.
Proactive Workflow Hygiene: Audits repository workflows for missing concurrency blocks and generates 1-click YAML fixes.
AI Failure Investigation: The moment a build fails, an integrated AI agent pulls the raw runner logs, redacts secrets, diagnoses the exact root cause, pinpoints the failed step, categorizes the bug, and provides copy-paste solutions.
Human-in-the-Loop Control Plane: Includes a kill switch, dry-run observation safety rails, team approvals for cancellations, and interactive ROI spend simulators.

Demo

🌐 Live Dashboard: ci-watchdog.vercel.app
🧪 Live Demo Pull Request: Live Demo

Key Features to Explore

Route	Feature	Description
`/app`	Control Room Overview	Live and dry-run minutes-saved counters, real-time system status indicators, and weekly savings charts.
`/app/investigations`	AI Investigations	Instant root-cause diagnostic cards generated by Gemma / Gemini 3.8 Flash, with failure hypotheses, log evidence snippets, and recommended next steps.
`/app/decisions`	Decision Engine & CSV Export	Full searchable decision history with rule and status filters, plus 1-click CSV download for engineering management reports.
`/app/approvals`	Human Approval Queue	First-N quota approval flow with 1-click Approve and Deny buttons.
`/app/digest`	Interactive ROI Calculator	Real-time savings simulator modeling monthly minute volume and runner tiers (see pricing below).

Runner pricing used in the ROI calculator:

Runner	Cost per minute
Ubuntu	$0.008
Windows	$0.016
macOS	$0.080
Apple Silicon (M-series)	$0.160

Code

The entire codebase is open-source and structured as a high-performance TypeScript monorepo using Turborepo and pnpm:

👉 Tusharkhadde/CI-watchdog

Path	Description
`apps/watchdog`	Event-driven Node.js background service deployed on Render. Connects to the GitHub App webhook stream, processes workflow states, runs the pure rule engine, and coordinates AI triage.
`apps/dashboard`	Next.js 16 (Turbopack) dashboard deployed on Vercel with Shadcn UI, Auth.js (OAuth with GitHub & Google), and real-time state synchronization.
`config/watchdog.yml`	Declarative team policies with per-repository overrides.

How I Built It

Architecture Overview

1. Pure, Deterministic Rule Engine

The rule engine (apps/watchdog/src/rules/) was designed to be 100% pure with zero side effects. Given the current run, sibling runs, historical durations, and workflow YAML, it evaluates four rules:

Rule	Behavior
`SUPERSEDED`	Cancels older runs queued on the same ref when a newer commit arrives.
`RUNAWAY_DURATION`	Compares running jobs against historical p95 execution times and alerts/cancels if a job hangs.
`MISSING_CONCURRENCY`	Scans workflow ASTs and alerts if jobs lack top-level concurrency cancellation blocks.
`STALE_ON_CLOSE`	Immediately terminates active pipelines when a PR is merged or closed.

2. Intelligent AI Failure Triage

When a workflow concludes with a failure, CI Watchdog activates the AI investigator:

Fetches the raw runner logs via the GitHub API.
Runs pattern redaction to scrub tokens and sensitive credentials.
Dispatches the condensed failure excerpt to open-weight models (Google Gemma / Gemini 3.8 Flash via OpenAI-compatible endpoints).
Validates the output with Zod, enforcing structured JSON containing:

Field	Description
`rootCause`	Explicit technical diagnosis (e.g., missing Docker service container, database port refusal).
`failedStep`	Exact bash command or step name that exited non-zero.
`category`	One of: Infrastructure, Configuration, Test, or Code.
`nextSteps`	Concrete remediation actions.

3. Safety Rails & Human-in-the-Loop

Automated cancellation can be intimidating for developers, so I implemented strict safety rails:

Default Dry-Run Mode: Repositories begin in observation mode so teams can review what would have been canceled without impacting active builds.
48-Hour Observation Window: Go-live can only be unlocked after a repository has been observed.
First-N Live Approval Quota: The first cancellations require explicit human confirmation via dashboard or Slack buttons.
Protected Branch Immunity: Never cancels main, master, or release/* branches.
Global Kill Switch: Instantly pauses all active cancellations across all repositories.

Why Does Open Innovation Matter?

Open innovation is what makes a tool like CI Watchdog possible without compromising developer trust:

Data Sovereignty & Privacy: Build logs often contain internal paths, dependencies, proprietary package names, and sensitive environment details. Relying on closed, proprietary cloud AI black boxes creates data-leakage risks for enterprise codebases. Open-weight models like Gemma enable teams to run AI failure analysis locally or within their own private infrastructure.
Deterministic Customization: Open tooling and open protocols allow developers to customize rule thresholds, inspect prompts, tune temperature, and swap backend models based on compute constraints.
No Vendor Lock-In: Developers shouldn't need a six-figure enterprise contract just to know why their CI pipeline broke or to prevent redundant job execution. Open innovation democratizes cost control for individual creators, open-source maintainers, and startups alike.

Prize Categories

Build for a Friend
Open Innovation & Open-Weight AI

Built with ❤️ during Hacktoberfest. If your team is burning minutes on redundant CI runs, give CI Watchdog a spin!

DEV Community: Tushar Khadde

🦥 DrawBoard: Letting an Open-Weight Agent Do the Drawing So You Don't Have To

What I Built

Demo

drawrboard-1.mp4 - Google Drive

Code

Tusharkhadde / draw-board

🎨 Drawboard

Overview

Table of contents

Tech stack

How I Built It

Why Does Open Innovation Matter?

My Agent Session

The Lazy Payoff

MenuPage: Helping Small Restaurants Go Digital with AI 🍽️

🍽️ MenuPage — A Digital Menu Platform for Small Restaurants

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

Prize Categories

🌿 Side Quest: An Open-Source AI Agent That Turns Screen Time into Real-World Adventures

🌿 Side Quest: An Open-Source AI Agent That Gets You Off Your Screen

What I Built

Demo

How I Built It

The open-source AI stack

How the agent works

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

CI Watchdog — The Autonomous CI Minutes & Spend Sentinel with Open AI Failure Triage

CI Watchdog

What I Built

Demo

Key Features to Explore

Code

How I Built It

Architecture Overview

1. Pure, Deterministic Rule Engine

2. Intelligent AI Failure Triage

3. Safety Rails & Human-in-the-Loop

Why Does Open Innovation Matter?

Prize Categories