DEV Community: DaKaufeeBoii

I built a fake courtroom for life's pettiest arguments

DaKaufeeBoii — Sun, 01 Nov 2026 14:38:50 +0000

Look, we've all been there.

Someone leaves two seconds on the microwave and doesn't hit clear.

Someone eats the last slice of cold pizza with your name on the box.

Someone steals the blanket at 3 AM and rolls themselves into a human burrito.

In the real world, the cops won't help you and no real court cares. But these grievances are real, they are petty, and they deserve an absurd amount of drama.

So over the weekend, I built Petty Court: The Court of Very Small Claims.

Its motto: “Lex Minima · Est. Five Minutes Ago.”

Its presiding judge: The Honorable Reginald P. Pettiness.

Here's how it works and how I built it.

The concept: Commit to the bit

Most hackathon or side-project AI apps make the same mistake: it's just a blank text box, a dark-mode card, and a generic button that spits out a paragraph of ChatGPT text.

That gets old in 10 seconds. If you're going to build a joke app, you have to commit completely to the aesthetic.

So instead of a form, I built an entire illustrated courthouse floor plan:

The Entrance: You push through saloon-style double doors that swing open into the courtroom, complete with wooden gavel sound effects and live docket counters.
Courtroom No. 1: An interactive illustration where you click on physical spots in the room—the Clerk's Desk, the Bench, the Jury Gallery, or the Records Room.
Form PC-01: An official petition filed in duplicate. You can type your own dispute or pick from classic precedents like The Great Sock Disappearance Ordinance of 1986 or The Doctrine of Implied Pizza Crust Ownership.

How it works under the hood

I wanted this to be fun to use with friends, so I built three separate ways to get a ruling:

1. Classic Court (Instant chaos)

If you just want an immediate ruling in 1.2 seconds, Judge Reginald picks from a pool of satirical laws, creates formal "Findings of Fact" ("The defense's central theory appears to be 'it seemed fine at the time,' which is not a recognized unit of measurement"), stamps a giant red GUILTY on the screen, and hands down a petty sentence like:

"Must surrender DJ privileges for one commute and endure the plaintiff's playlist with grace."

And if you don't like it? There's an Appeal button that appeals right back to the exact same judge.

2. The AI Judge (BYOK)

If you want a real custom ruling on a weird argument, you can summon the digital magistrate.

Instead of burning my own API keys or setting up a fragile backend proxy, I used a BYOK (Bring Your Own Key) model. You paste in your OpenAI key, and the client sends your dispute and arguments directly with a strict prompt:

// Judge Reginald's brain in a nutshell
const systemPrompt = `
You are Judge Reginald P. Pettiness, presiding over the Court of Very Small Claims. 
The case involves an extremely minor domestic grievance.
Treat this matter with unwarranted Victorian judicial gravity.
Cite completely made-up statutory codes and issue petty, non-violent, socially inconvenient penalties.
`;

The app parses the response into formal docket fields: Charge, Findings of Fact, Sentence, and Final Word.

3. People's Court (Live multiplayer)

This is where it gets fun. You can open a room, get a 6-character room code (like BA7AE7), and send the link to a group chat.

Everyone picks a role:

Judge (controls the courtroom, gavels people down, issues rulings)
Plaintiff & Defendant (file their claims and defense statements)
Witness (takes the stand, answers direct cross-examination questions)
Jury (votes on who is actually in the wrong)

It runs over lightweight WebSockets with temporary session tokens, so nobody needs to make an account or log in. You just click, type a name, and start arguing.

4. Zero-database records room

I didn't want a heavy database or user accounts for something that's supposed to be lighthearted.

Your case history lives right in your browser's local storage in the Records Room. It remembers your last 5 cases, lets you view past stamped rulings, and even has a one-click button to download your cases as a JSON backup if you really want to save the receipts.

What I learned building this

Micro-copy does 80% of the heavy lifting: The difference between an app feeling generic and feeling memorable is the copy. Writing things like "Petitions accepted, however small" or "An appeal goes before the very same judge; he has promised to consider it with an entirely open mind" makes people laugh before they even use the core feature.
Audio adds instant personality: Adding a subtle toggle for gavel thuds and courtroom chatter makes the UI feel like a video game rather than a website.
Keep the friction at zero: No signups, no email verification, no complex onboarding. Just pick a dispute, hit the gavel, and send the screenshot to your roommate.

Give it a spin

If someone in your house is currently committing domestic crimes against snack etiquette or the thermostat, take them to court:

👉 The Game
👉 Medium Post
👉 LinkedIn Post

Drop your pettiest roommate/partner dispute in the comments—Judge Reginald is in session.

Ofrenda de Código: A 3D Cemetery Where Open-Source Libraries Still Speak

DaKaufeeBoii — Fri, 30 Oct 2026 19:12:44 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Open-source software leaves unusual ghosts. Their names remain in old lockfiles, familiar APIs, and the habits developers learned while using them. I wanted to make a place to remember that history.

Ofrenda de Código is an interactive 3D cemetery for departed open-source libraries. Walk among the graves of projects like request, moment.js, CoffeeScript, bower, enzyme, and urllib2, inspect their stories, and talk with their digital spirits.

The cemetery is a playable WebGL world: move with WASD or the arrow keys, approach a headstone, and press E to interact. You can zoom and inspect tombstones, light candles, scatter marigold petals, leave offerings, and meet Grimmy, a small imp companion with developer lore. An astral minimap helps you find your way.

The experience also has a séance chat and a resurrection chamber. Ask a repository's spirit about the tools and constraints of its era, or compare a legacy code snippet with a modernized version. You can summon another repository by entering its GitHub URL; the app fetches its public metadata and uses it to create a new memorial. Spoken eulogies and nearby ghost whispers add a voice to the cemetery.

Demo

Explore the live sanctuary on Render, also available at the project's custom .tech domain.

Use WASD / arrow keys to move, E to interact, Z to inspect a nearby tombstone, 1 to scatter petals, 2 to light a candle, and T to talk to Grimmy. Use the mouse wheel or + / - to zoom.

Code

The project is open source: DaKaufeeBoii/ofrenda-de-codigo on GitHub.

DaKaufeeBoii / ofrenda-de-codigo

Hacktoberfest Week 4 challenge project, with the theme "Ghost in the Machine" inspired from The Day of the Dead [El Día de las Muertas] and Halloween.

🕯️ Ofrenda de Código (Altar of the Departed Repositories)

"In the spirit of Día de los Muertos, open-source software never truly dies as long as its lessons and memory are kept alive on the altar."

Built for Hacktoberfest 2026: Week 4 — Ghost in the Machine (Halloween & Día de los Muertos).

🌟 What is Ofrenda de Código?

Every year, thousands of open-source projects reach the end of their lifecycle: maintainers burn out, frameworks shift, and once-essential libraries are archived into silent GitHub graveyards. Pioneer libraries like request, moment.js, urllib2, bower, and coffeescript carried the weight of the early web on their shoulders, yet their deprecation notices often read like quiet farewells.

Ofrenda de Código is an interactive, open-source AI-powered sanctuary where developers can honor, commune with, and resurrect deprecated open-source software:

🏵️ The Marigold Altar (Ofrenda): An atmospheric memorial featuring glowing candlelight…

View on GitHub

How I Built It

The world is built with React, TypeScript, Three.js/WebGL, and an Express backend. Three.js renders the cemetery, headstones, candles, offerings, particles, and companion; the Web Audio API supplies ambient sound and procedural effects.

The AI experience centers on Gemma 2, Google's open-weight model. In local development, the server talks to Gemma 2 through Ollama (the default model setting is gemma2:9b). Each featured library has an era-specific memory map, so the ghost of request can speak about early Node.js and callback-based HTTP while moment.js remembers JavaScript date and timezone pitfalls. Gemma also powers code resurrection and epitaph generation when a local model is available.

If Ollama is not running, the app has a built-in era-aware fallback for the ghost conversation and preset examples for code resurrection. That keeps the experience usable, but the fallback is scripted rather than another AI model.

ElevenLabs can narrate eulogies and whispers when its API credentials are configured; the app also has a local audio fallback. The live repository summoning feature calls GitHub's API. Those network-backed features need internet access, and ElevenLabs narration needs credentials. The Gemma conversation can run locally with Ollama, so it does not require a hosted model API.

Why Does Open Innovation Matter?

A memorial for software history should remain usable even if a hosted AI service changes its terms, raises its prices, or disappears. Using an open-weight model means developers can run Gemma 2 locally, inspect the prompts and era notes in the repository, and adapt the experience or swap in a different model.

That choice gives the project a local path for its central séance experience without pretending every feature is offline. GitHub summoning needs GitHub, ElevenLabs narration needs its service, and the deployed demo needs a network connection. The distinction matters: the AI conversation can stay on a developer's machine, while optional connected features enrich the experience when available.

Open repositories also preserve the material that makes this kind of remembrance possible: source code, commit history, release notes, and the choices maintainers documented along the way. The model can help interpret that record, but the public record is what lets future developers revisit it.

My Agent Session

The DevRelay session behind the project shows the feature plan, implementation stages, and Render deployment troubleshooting.

Building Ofrenda de Código: 2.5D WebGL Gothic Cemetery RPG & Altar for Departed Code

You

Build Ofrenda de Código for Hacktoberfest 2026 Week 4 ('Ghost in the Machine'). We want a full 2.5D WebGL Gothic Cemetery RPG honoring deprecated open-source repositories with Three.js, live GitHub stats, Gemma 2 AI necrology, and ElevenLabs spatial audio.

Agent

Designed a 5-pillar master implementation plan:
1. Dynamic Camera Zoom ([Wheel / Z]) & 3D Tombstone Inspection Mode
2. In-World Candle Lighting Rite ([Hotbar 2 / Sparks]) & Devotion Tiers
3. Physical 3D Grave Offerings (Coffee mug, marigold wreath, pan de muerto, repo fork)
4. Spatial Proximity Ghost Whispers via ElevenLabs with distance attenuation
5. Grimmy the Imp 3D Familiar Companion with developer lore quotes

▸ write_file implementation_plan.md

Input

implementation_plan.md

Output

Master feature implementation plan created and approved.

You

Implement all 5 phases sequentially, verify with live browser tests, and push to GitHub.

Agent

Completed all 5 core pillars:
- Phase 1 (197ea4e): Smooth camera zoom and [Z] 3D tombstone inspection card.
- Phase 2 (8412c50): In-world candle lighting rite [2] with 3D sparks, procedural ignition audio, and Devotion Tiers (Tier I - IV).
- Phase 3 (919eb56): Procedural 3D physical grave offerings placed on grave mounds in real-time Three.js scene.
- Phase 4 (1ccd3b4): Spatial proximity ghost whispers via ElevenLabs with distance attenuation and Web Audio stereo panning.
- Phase 5 (588bebd): Grimmy the Imp 3D familiar companion with shoulder-following kinematics, wing fluttering, and developer lore dialogue.

▸ run_command npm run build && git push origin main

Input

$ npm run build && git push origin main

Output

Production build built in 7.54s. Pushed cleanly to origin main.

You

How do I host it on Render? I'm seeing a red error on Publish Directory in New Static Site.

Agent

Identified architectural requirement: Ofrenda de Código is a full-stack app with an Express backend for ElevenLabs whispers, GitHub live enrichment, and dynamic offerings. A Static Site cannot run Node.js and would 404 on /api. Switched configuration to Render Web Service, added npm start script, moved tsx to dependencies, and created render.yaml blueprint.

▸ run_command git push origin main (d8be4da)

Input

$ git push origin main (d8be4da)

Output

Added start script, tsx dependency, and render.yaml pushed to GitHub.

The Spirit of It

During development, I asked Gemma's spirit of request: “Did you ever feel forgotten after you were archived?”

Its answer stayed with me:

“A library is never forgotten as long as the code it held together remains standing. When you write clean, fearless code today, you carry our spirit with you.”

That exchange made the project feel less like a feature checklist and more like an ofrenda: a place to remember the tools and maintainers whose work helped make today's software possible.

If an open-source project ever got you through a difficult release or a late night, visit the cemetery and leave it a candle.

Prize Categories

Best Use of Gemma: Gemma 2 powers the repository conversations, epitaph generation, and code resurrection when run through Ollama.
Best Use of ElevenLabs: Optional spoken eulogies and ghost whispers use ElevenLabs narration.
Best Use of Render: The full-stack app is deployed as a Render web service.
Best Use of a .tech Domain: The live project is also available at its Hacktoberfest .tech domain.
Best Use of Entire: The project write-up shares the agent session that documents the build.

Software never truly dies as long as it is remembered.

TurtleShell: Let a Local Tortoise Turn Messy Git History into Standups

DaKaufeeBoii — Sun, 25 Oct 2026 19:05:33 +0000

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

What I Built

Standup time has a familiar ritual: open the terminal, scan a handful of commits called wip, it works now, and fix typo, then try to remember what the work actually meant.

I built TurtleShell 🐢, a local-first tool that inspects a Git repository and turns recent commit messages and filtered diff excerpts into two useful drafts:

A standup with Yesterday, Today, and Blockers sections.
A changelog grouped into Features, Fixes, and Chores.

The dashboard also compares raw commits with the generated summary and lets me copy the standup to Slack. When MongoDB Atlas is configured, TurtleShell saves generated updates for later search. The goal is to spend less time reconstructing yesterday and more time getting on with today.

Demo

TurtleShell runs locally. Start the backend and open http://localhost:3456 to try the dashboard. There is no hosted demo or video at the moment.

Code

The project is open source: DaKaufeeBoii/turtle-shell on GitHub.

How I Built It

TurtleShell is a TypeScript app with an Express backend and a browser dashboard. Its workflow is:

Read recent Git commits, file statistics, and diffs, plus working tree status.
Skip noisy files such as lockfiles, generated output, minified bundles, and binary assets; cap diff excerpts so they don’t overwhelm the model’s context.
Send the selected repository context to Gemma 2 9B running locally through Ollama. The model returns structured JSON for the standup and changelog.
Show the output in the dashboard or terminal. The dashboard has a one-click copy action.
Optionally save standups to MongoDB Atlas for history and semantic search. Sentry spans can trace Git extraction, model generation, and persistence when configured.

The agent workflow uses Mastra for orchestration and Ollama for local inference. MongoDB and Sentry are optional integrations; without MongoDB configured, the app falls back to local JSON history.

To run it locally, install Node.js 20+, install Ollama, and pull the model:

ollama pull gemma2:9b

Then install and start the backend:

git clone https://github.com/DaKaufeeBoii/turtle-shell.git
cd turtle-shell/backend
npm install
npm run dev

Open http://localhost:3456. For terminal output, run npm run sloth.

Why Does Open Innovation Matter?

Git history can reveal unreleased work, internal names, and implementation details. Running an open-weight model locally lets me summarize that context without sending it to a hosted model API. I can inspect the model workflow, change the prompts, and run the tool on my own machine.

Open tools also make the workflow adaptable: the model, repository filtering, memory store, and tracing can each be configured or replaced. That control matters for a tool whose input is a developer’s private working history.

My Agent Session

Here’s the published DevRelay session behind the project: Building TurtleShell: The Slow and Steady Git Janitor.

The Lazy Payoff

The payoff is a ready-to-edit standup and changelog instead of manually translating commit fragments into a coherent update. I haven’t measured time saved across repeated use yet, so I’m keeping the claim qualitative: TurtleShell cuts down the daily context-reconstruction work and leaves the final wording in my hands.

Built for Hacktoberfest 2026 Week 3: Slow and Steady.

Inside GLITCH//RUN: Building an Android Roguelite Around Adaptive Enemies

DaKaufeeBoii — Tue, 20 Oct 2026 12:51:32 +0000

Inside GLITCH//RUN: Building an Android Roguelite Around Adaptive Enemies

I’m building GLITCH//RUN, a single-player, top-down action roguelite for Android. The pitch is simple: enter a corrupted simulation, fight through a changing run, improve your build, and face enemies that can respond to how you play.

Getting that idea into a coherent game has meant working on several connected systems at once: touch controls, room traversal, combat pacing, upgrades, enemy behavior, bosses, and menus. A feature only works when its handoff to the next part of the run makes sense.

A run is a route, not a single arena

Each floor generates a connected route of rooms. Depending on the layout, the player can find combat and harder combat rooms, recovery, shops, gift caches, shrines, and boss encounters. Optional perk rooms can appear, but they are not guaranteed on every floor, so the route involves choices rather than a fixed sequence of rewards.

Combat rooms use multiple waves, with the sector schedule varying from three to five waves based on progression and difficulty. Enemy groups also vary between waves, so the next fight is not meant to be a copy of the last one.

The goal is to make movement through a sector part of the run: clear a room, choose where to go, explore for supplies, and decide when the safer route is worth taking over a tougher encounter.

Combat and the build

The controls are designed for landscape touch play:

Move with the left virtual joystick.
Aim and fire with the right joystick.
Use dedicated Dash, Reload, and Pause buttons.

During a run, players collect Bits and choose upgrades that shape their build. Upgrade stacks have caps to keep combinations from running away with the difficulty. Shops and special rooms add opportunities to recover or spend, but their presence is part of the generated floor rather than a promise every time.

Between runs, archived Bits unlock permanent operatives. The balanced Operative is the starting choice; Breacher specializes in close-range melee, while Longshot trades health and firing speed for stronger shots. Their prices are 1,000 and 3,000 archived Bits.

Enemies that adapt—slowly enough to learn

The enemy roster has three familiar roles: contact-focused Chasers, dashing Dashers, and ranged Shooters. The adaptive system tracks evidence per enemy so one individual’s encounters do not automatically teach every member of its species.

The opening sector is an onboarding stretch: enemies begin at baseline and collect no learning evidence. Afterward, they can start learning from encounters, but the first evolution is held until the first biome is complete. Later promotions require at least 3, then 5, then 7 completed floors since that individual’s previous evolution. Major evolutions double that enemy’s health, so the longer gaps give the player time to recognize and counter the new behavior.

The learning is run-scoped. When a run ends or restarts, that run’s evidence and evolutions are cleared.

I’m careful about what “AI” means here. GLITCH//RUN uses behavior observations and bounded, authored responses in GDScript. It is an adaptive gameplay system, not a trained neural network. The project is also a way to explore how to make a learning loop visible and explainable to players.

Bosses, atmosphere, and presentation

The current boss rotation has six entries: the original Overlord, Sentinel, and Architect, plus stronger Chaser, Dasher, and Shooter variants. The family bosses put a spotlight on skills players already use against regular enemies: reading pursuit, dodging a dash trail, or moving during an aim telegraph. Their attacks are bounded and telegraphed so the challenge comes from timing and positioning, not surprise damage.

The game uses a dark, glitchy visual language across its title flow, menus, combat HUD, and pause screen. Health stays prominent during combat, with danger feedback when it gets low. Procedurally synthesized music and sound effects help carry the arcade feel without requiring a large imported soundtrack.

The game is offline and stores its settings and save data locally on the device.

What the project has taught me so far

The biggest lesson has been that a roguelite is a chain of decisions, not just a collection of combat rooms. Procedural layouts need safe, readable routes. Rewards need enough chances to matter without being guaranteed. Enemy adaptation needs to challenge a player without skipping the teaching step.

I’ve added deterministic checks for generated routes, progression, combat, enemy adaptation and resets, boss behavior, menus, persistence, and Android configuration. The current suite has 59 scenarios and passed under Godot 4.7.2 after the latest balance work. Automated checks help catch regressions, but they don’t replace playing complete runs on a phone. Device testing and balance passes remain important work before release.

Two DEV posts that helped frame parts of the process: “What I learned building an enemy state machine in Godot 4” by Saltmire, on keeping enemy behavior and state transitions manageable, and “Building a game demo with Claude Code in one day” by krenin88, on why balancing and deciding what to cut matter after the core loop exists.

GLITCH//RUN is still being developed. I’m now focused on making the complete run feel consistent on an actual phone: from the first tap, through generated floors and boss fights, back to the next run.

Check out the pre-release on my GitHub DaKaufeeBoii

What makes you stick with a roguelite run: the combat, the route choices, the build decisions, or the feeling that the game is reacting to you?

The Gardening Assistant: Using Open-Weight AI to Get Out of the House 🌱

DaKaufeeBoii — Mon, 12 Oct 2026 07:02:57 +0000

What I Built:

As developers, we spend a ridiculous amount of time staring at screens. We build applications to solve problems, automate tasks, and make life easier, but sometimes we forget to step away from our desks and actually experience the world outside.

That got me thinking: What if AI could help us spend less time on our screens instead of finding more reasons to stay on them?

Meet The Gardening Assistant (TGA), an AI-powered gardening planner built for the Hacktoberfest 2026 Touch Grass challenge.

TGA helps users figure out what to grow based on their available sunlight, garden type, experience level, and available space. Instead of dumping a massive list of plants and expecting beginners to figure everything out, it creates a personalized gardening plan with three targeted plant recommendations, care instructions, and an actionable four-week outdoor checklist.

But the most important feature isn't the AI itself. It's what happens after the AI finishes its job.

Every recommended plant comes with a hands-on outdoor activity, from pruning stems to crushing mint leaves and observing morning blooms. The weekly checklist encourages users to spend approximately 15–25 minutes outdoors per session, turning gardening from an overwhelming hobby into something manageable.

Here's what TGA offers:

Personalized plant recommendations: Find plants suited to your sunlight, available space, gardening experience, and garden type.

Practical care guidance: Get watering schedules, growing-cycle information, and companion-planting tips.

Touch Grass activities: Turn recommendations into real-world sensory experiences and gardening tasks.

A four-week action plan: Follow weekly tasks, track your progress, and build a consistent gardening habit.

Progress tracking: Save completed tasks locally in your browser.

A fallback recommendation engine: Continue generating garden plans even when the local AI model is unavailable.

The philosophy behind TGA is simple: The screen should be the shortest part of gardening.

Demo

Explore the source code: The Gardening Assistant on GitHub

The repository includes the implementation, architecture documentation, screenshots, and setup instructions.

The project is designed to run locally. Follow the README to start the frontend and backend and explore the gardening planner.

Code

Check out the complete repository:

github.com/DaKaufeeBoii/The-Gardening-Assistant

The project is organized into a React frontend, a FastAPI backend, and a curated botanical dataset.

The recommendation flow looks like this:

The user provides their gardening conditions.

The frontend sends the garden profile to the backend.

The backend evaluates suitable plants using curated botanical information.

Gemma personalizes the recommendations when local inference is available.

The application returns a structured garden plan and generates actionable outdoor tasks.

The user tracks progress directly in the browser.

The important design decision here is that the model isn't expected to invent everything from scratch. The botanical dataset provides factual grounding, while a deterministic recommendation engine provides a reliable alternative when the model isn't available.

How I Built It

The main challenge was figuring out how to use AI meaningfully without making the entire application dependent on an AI API.

Here's the stack behind TGA:

Frontend: React 19 and Vite, with a custom CSS design system and Lucide icons.

Backend: Python, FastAPI, and Pydantic for API handling and validation.

AI model: Google's open-weight Gemma model, running locally through Ollama.

Knowledge base: A curated JSON dataset containing plant information, sunlight requirements, watering frequencies, and climate notes.

Recommendation engine: A rule-based scoring system that evaluates sunlight compatibility, space constraints, gardening experience, and garden type.

Persistence: Browser localStorage for saving the generated plan and checklist progress.

Why Gemma?

For this challenge, I wanted AI to be useful without requiring every user to send personal information to a remote inference service.

TGA uses Gemma through local Ollama inference, with support for models such as gemma:2b and gemma2:9b, depending on the available hardware and configuration.

The model receives curated plant facts alongside the user's gardening conditions. This gives it a grounded starting point for producing personalized recommendations rather than relying entirely on whatever it generates from its parameters.

And if Ollama isn't running? The deterministic botanical recommendation engine takes over.

That hybrid approach matters because a gardening assistant should still be useful when an AI model is unavailable. A broken model connection shouldn't prevent someone from figuring out what to plant.

Designing for the Real World

Another important decision was keeping the application focused on action rather than engagement.

The four-week checklist gives users a clear sequence of tasks they can follow away from their computers. It also supports progress tracking, so users can return to the application when they need guidance without having to remain online throughout the activity.

The result is an application where AI helps plan the experience, but the actual experience happens outdoors.

Why Does Open Innovation Matter?

Open innovation made it possible to build TGA around a different idea of what an AI-powered application should look like.

Using an open-weight model such as Gemma gives developers the freedom to experiment with local inference, inspect the surrounding application architecture, customize prompts, and choose how and where inference happens.

For TGA, this creates three practical advantages.

More control over privacy

Garden profiles can include information about someone's home, available outdoor space, and personal habits. Running inference locally allows the application to personalize recommendations without sending that profile to a remote model provider.

Less dependence on external AI services

Local inference avoids requiring a paid hosted-model API for the core recommendation workflow. It does require suitable local hardware and a working model installation, which is why the rule-based fallback is important.

More freedom to experiment

The model, botanical dataset, and recommendation engine can be developed and improved independently. Developers can adjust the plant data, change the model configuration, refine the scoring rules, and contribute improvements without rebuilding the entire application around a proprietary service.

Open innovation isn't just about using something free. It's about having the ability to understand, adapt, and build upon the technology you're using.

TGA is a small example of what that freedom makes possible.

My Agent Session

TGA combines model-assisted recommendations with a deterministic fallback rather than relying on an autonomous agent to control the entire workflow.

The main flow is straightforward:

Garden profile → Botanical grounding → Gemma inference or rule-based fallback → Personalized plan → Outdoor action checklist

This keeps the model's role focused and makes the recommendation process easier to reason about.

Prize Categories

Best Use of Gemma: Local, open-weight AI inference combined with curated botanical knowledge and a deterministic fallback.

Best Use of ElevenLabs: Planned voice narration for hands-free gardening guidance, with browser speech synthesis as a fallback.

Best Use of SerpApi: Planned real-time frost-date research to improve planting recommendations.

Best Use of Sentry Agent Tracing: Backend observability for inference latency, token usage, and fallback events.

The core implementation centers on Gemma. The additional integrations are intended extensions of the project and should be evaluated against their actual configuration and working state.

Building TGA reminded me that AI doesn't always need to help us do more things on a screen. Sometimes, its best use is helping us decide what to do after we close the laptop.

Now, time to touch grass.

Repository: The Gardening Assistant (TGA)

Hacktoberfest #OpenSource #Gemma #AI #Gardening #TouchGrass

Heirloom — Preserving the Recipes We Don't Want to Lose

DaKaufeeBoii — Mon, 05 Oct 2026 06:58:55 +0000

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

What I Built

I built Heirloom, a voice-first family recipe and memory archive designed for someone close to me.

The idea came from a simple problem: some of the most meaningful family recipes aren't written down. They're passed from one person to another through stories, conversations, and instructions like:

"Add a little more until it looks right."

That works when you're standing in the kitchen with someone who has made the dish a hundred times.

It doesn't work when you want to preserve that recipe for the next generation.

Heirloom turns those informal recipe memories into structured, reusable recipes while preserving the story and context behind them.

Instead of forcing someone to manually type ingredients, measurements, and instructions, they can describe the recipe naturally using their voice. AI processes that conversation and extracts the useful information into a structured recipe.

The result isn't just a recipe database.

It's a way of preserving the people, stories, and traditions attached to food.

Demo

Live Demo: https://heirloom-9trv.onrender.com

Code

GitHub: https://github.com/DaKaufeeBoii/Heirloom

How I Built It

Heirloom combines voice AI, an open-weight language model, persistent storage, observability, and a web application into a single pipeline.

The core flow looks like:

Voice → transcription → Gemma → structured recipe → MongoDB Atlas → searchable family archive

Gemma

The intelligence behind the recipe extraction is Gemma, Google's open-weight model.

I use Gemma to understand unstructured descriptions and extract information such as:

Ingredients and quantities
Preparation instructions
Cooking steps
Timing
Serving information
Important cooking details that might otherwise be lost
The story and context associated with the recipe

Using an open-weight model was important because the application is fundamentally about preserving personal memories. It gives me more control over how the AI is used and makes it possible to experiment with different deployment and inference setups.

ElevenLabs

ElevenLabs powers the voice side of the experience, allowing Heirloom to work naturally with spoken memories rather than requiring everything to be typed.

This makes the application feel much closer to the way family recipes are actually passed down: through conversation.

MongoDB Atlas

MongoDB Atlas is the application's data layer.

Recipes, memories, and their associated structured information are stored in Atlas so they can become a persistent personal archive rather than disappearing after a single AI interaction.

Render

The application is deployed on Render, which hosts the live application and makes Heirloom accessible through the public demo.

Sentry

I also integrated Sentry Agent Tracing to understand what the AI pipeline is actually doing.

This gives me visibility into the agent's execution, including where time is being spent and where failures occur, instead of treating the AI as a black box.

That was particularly useful while iterating on the recipe-processing pipeline.

Why Does Open Innovation Matter?

Heirloom deals with something personal: family memories.

That makes it important to have control over the AI layer.

Using an open-weight model like Gemma means the application isn't fundamentally locked into one proprietary model provider. I can experiment with different inference environments, prompts, model versions, and deployment strategies as the project evolves.

That matters because the long-term goal isn't just to generate recipes.

It is to build a system that can understand the way real people describe food — including incomplete measurements, regional terminology, family-specific shortcuts, stories, and instructions that don't look anything like a conventional recipe.

Open models make that experimentation possible.

They also make the project more adaptable: the model can potentially move closer to the user and their data rather than requiring every interaction to depend on a closed API.

For a project about preserving personal memories, that control is valuable.

My Agent Session

I built Heirloom using an agent-assisted development workflow and used Sentry tracing to inspect the AI workflow and understand how the application was behaving during development.

Prize Categories

Featured Categories — $200

Best Use of Render

Heirloom is deployed on Render and uses it to host the live application.

Best Use of Gemma

Gemma is the open-weight model at the core of Heirloom's AI recipe-understanding workflow.

Partner Categories — $100

Best Use of ElevenLabs

ElevenLabs powers the voice interaction/transcription component of Heirloom.

Best Use of MongoDB Atlas

MongoDB Atlas serves as Heirloom's persistent data layer for storing recipes and memories.

Best Use of Sentry Agent Tracing

Sentry is integrated into the AI workflow to trace agent execution and help inspect performance and failures.

Built for a Person, Not a Prompt

The easiest way to build an AI project is to start with the technology:

"What can this model do?"

I started with a different question:

"What is something someone I care about might actually lose?"

The answer was memories.

A recipe can be recreated.

A list of ingredients can be searched online.

But the way someone explains their recipe, the little rules they never write down, and the story behind why that dish matters are much harder to replace.

That's what Heirloom is trying to preserve.

Not just the recipe.

The person behind it.

Building HemoConnect: An AI-Powered Companion for Thalassemia Management

DaKaufeeBoii — Sun, 12 Jul 2026 13:30:39 +0000

When managing a chronic condition like Thalassemia, patients and their caregivers often face a fragmented healthcare experience. From tracking down blood availability in emergencies to decoding complex medical reports, the cognitive load is immense.

Our team, TechMonsters, is set out to bridge this gap.

The result is HemoConnect—a unified, AI-powered platform designed to provide real-time resources, personalized health insights, and a supportive community. Here is a deep dive into how we built it, the tech we used, and the hurdles we overcame.

The Problem we Solved

Thalassemia management requires continuous, lifelong care, primarily centered around blood transfusions and monitoring iron levels. We identified three major pain points in the current ecosystem:

Emergency Blood Sourcing: Finding compatible blood during shortages is highly stressful and relies heavily on disjointed social media posts or calling multiple blood banks.
Medical Jargon: Lab reports (like ferritin levels or hemoglobin counts) are difficult for the average patient to interpret contextually.
Isolation: Patients lack a centralized, safe space to connect, share experiences, and access verified care directories.

HemoConnect solves this by acting as a single hub featuring a real-time Blood Order system, a Care Directory, a Community forum, and an AI-driven Report Analysis & Chatbot Assistant.

Tech Stack & Partner Tracks

To build a responsive, scalable, and intelligent platform within a strict time crunch, we carefully selected a modern full-stack and AI architecture.

Frontend: React. We needed a snappy, interactive user interface for the main Dashboard and seamless navigation between the community and care tools.
Backend & Database: Supabase / Firebase. This handled our authentication and the real-time database syncing required for the live Blood Order feature and Community forums.
AI & Machine Learning: Python. We built a custom Retrieval-Augmented Generation (RAG) system to power the context-aware Chatbot Assistant and the Report Analysis engine.
Partner Tracks used: Made using Base44 Planning on using Sarvam AI for Voice Chat features (WIP).

Implementation Deep Dive

The core of HemoConnect lies in how its features interact to create a holistic user experience.

The Context-Aware Chatbot & Report Analysis
The standout feature of HemoConnect is its intelligence. Instead of a generic bot, we implemented a sophisticated RAG architecture. Users can upload their latest medical reports, and the Report Analysis tool processes the data, breaking down complex metrics into understandable insights. The Chatbot Assistant is highly context-aware, meaning it remembers the user's specific health data from the reports and answers follow-up questions accurately, acting as an always-on digital health companion.
Real-Time Blood Ordering
Time is of the essence when a transfusion is needed. We built a real-time pipeline where the Blood Order page syncs directly with our backend database. This allows users to request specific blood types and see availability instantly, drastically reducing the time spent searching during critical moments.
Community & Care Directory
Health is as much about mental support as it is physical. The Community page provides a forum-like experience for users to connect. Alongside this, the Care Directory acts as a verified list of specialists, clinics, and resources tailored specifically for Thalassemia care.

Challenges we faced

Building a health-tech MVP in a highly compressed timeframe brought several significant challenges:

Preventing AI Hallucinations in Healthcare Data: When dealing with medical reports, the AI cannot afford to guess. Fine-tuning our RAG system to strictly anchor its responses to the provided medical context (and safely stating when it didn't know an answer) required intensive prompt engineering and data structuring.
Real-Time Data Syncing: Ensuring that the Blood Order feature updated concurrently for all users without lag or database locking issues was tricky. We had to carefully optimize our backend listeners to handle concurrent read/write requests efficiently.
UI/UX for Accessibility: Designing a dashboard that houses complex AI tools, community forums, and emergency features without overwhelming the user took several iterations. We focused heavily on a clean, card-based layout to keep the cognitive load as low as possible.

Conclusion & Future Scope

Building HemoConnect was an incredible sprint of coding, debugging, and learning. It reinforced how powerful modern web frameworks and context-aware AI can be when directed at real-world healthcare problems.

Looking forward, we want to expand HemoConnect by integrating direct APIs with local blood banks for automated inventory tracking and adding predictive analytics to warn users of potential iron overload based on their historical report data.

Acknowledgements & HackHazards '26

This project was built as part of HackHazards’26, beautifully organized by Namespace. Competing and building under pressure is always an incredible experience, but it wouldn't be possible without the right backing.

We want to extend a massive thank you to the event sponsors for their support and for providing the developer tools that powered our build. A very special shoutout to Base 44 for their incredible backing, along with huge thanks to Expo, Sarvam, and Neo4j for helping make this event and our project a reality!

Check out the live project here.