DEV Community: Tanisha

# 👻 Archive Afterlife: Giving Forgotten Open-Source Software a Second Life

Tanisha — Tue, 27 Oct 2026 16:06:20 +0000

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

👻 Archive Afterlife: The Ghost in the Machine

Some code refuses to be forgotten.

What happens when a software project is abandoned? Its maintainers move on, its documentation gathers dust, and eventually, the ideas hidden inside its code risk disappearing into the digital dark ages.

But what if we could bring those projects back to life?

Meet Archive Afterlife — a haunted digital archive that lets you explore forgotten software, interrogate its ghost, uncover its architecture, and imagine its future.

Built for the final Hacktoberfest 2026 Open-Source AI Challenge, Ghost in the Machine, this project combines software archaeology, AI-assisted exploration, and a little Halloween magic. 🕯️

🏚️ What I Built

Archive Afterlife turns software documentation into an interactive archaeological experience. Instead of digging through old files alone, you can enter an archive, ask questions, investigate technical decisions, and generate a resurrection report.

👻 1. Enter the Haunted Archive

The experience begins with a simple message:

Some code refuses to be forgotten.

Explore four fictional software relics, each with its own technical history and architectural mysteries:

Phantasm Daemon (1999): A peer-to-peer hypermedia daemon.
AetherNet Crawler (2004): A semantic web crawler.
NecroOS Kernel Spec (2008): A capability-based microkernel.
ChronosDB (2011): An immutable time-series database concept.

Each archive offers a starting point for exploring the ideas, architecture, and potential future of forgotten software.

🗣️ 2. Summon the Ghost

What if you could interview an old codebase?

The interactive terminal lets you explore an archive through three distinct perspectives:

Maintainer Echo — explores the imagined design intent behind the project.
System Daemon — examines its low-level runtime concepts.
Code Archaeologist — investigates its architecture and technical trade-offs.

The experience is designed to distinguish documented facts from speculation. When information is missing, the archive explicitly marks it as [UNRECORDED IN CODEX] rather than inventing a historical answer.

📜 3. Bring Your Own Archive

Have an old project sitting on your machine?

Upload or drag and drop .txt, .md, .c, .h, or .py files into the Archive Ingestion Lab.

Archive Afterlife extracts document sections, reports file statistics, and identifies potential legacy concerns, including Python 2 dependencies, MD5 usage, select(2), and unbounded buffers.

Your uploaded material becomes the active archive, allowing you to investigate your own software relics.

🔎 4. Generate a Resurrection Report

Every forgotten project deserves a second chance.

The Resurrection Report generator creates a structured technical dossier containing:

Original purpose and historical context
Architecture and core primitives
Potentially obsolete dependencies and technical risks
Modernization opportunities and rewrite strategies
Unanswered questions and missing artifacts

Reports distinguish documented facts from technical hypotheses and can be exported as Markdown, printed, or copied for further analysis.

🧩 5. Follow the Evidence

An intriguing answer is not enough. Developers need to know where it came from.

The Evidence Trail connects citations in responses and reports to the relevant file, section, and line range. Selecting a citation highlights the corresponding passage in the Codex Inspector.

The idea is simple: make software archaeology easier to investigate, verify, and build upon.

🛠️ How I Built It

I used Google AI Studio's browser-based app-building workflow to develop Archive Afterlife through iterative prompting and refinement.

The application includes:

React and TypeScript for the interactive frontend and structured data.
A modular Gemma 2 integration for connecting the archive to an open-weight language model.
A server-side adapter to keep model integration separate from the user interface.
Structured archive data for immediately accessible sample projects.
Document ingestion and code-oriented analysis for exploring uploaded files.
An evidence-linked document viewer and an exportable report generator.

I also pushed the project to GitHub so its code can be explored and developed further.

🔗 GitHub Repository: https://github.com/Tanishaaaaaaa/ghost_challenge

🧠 Why Open-Weight AI?

The theme Ghost in the Machine inspired me to think about a broader question: what happens when the tools we depend on disappear?

Open-weight AI offers developers more flexibility in how they build and deploy AI-powered applications. Models such as Gemma can be used within systems that developers adapt to their own needs, subject to the relevant model license and deployment setup.

For Archive Afterlife, that philosophy matters in several ways.

🔓 Freedom to adapt

A modular model adapter makes it easier to evolve the inference layer without redesigning the entire application.

🗃️ Preserving technical knowledge

Software archives should remain useful beyond the lifetime of a particular AI service. Keeping project documentation and analysis workflows distinct from the model helps preserve that flexibility.

🔍 Transparency and evidence

The archive's evidence trail encourages developers to inspect source material instead of blindly trusting generated explanations.

🌱 Accessible experimentation

Sample archives and deterministic demo responses let users explore the experience without requiring a live inference connection just to try the interface.

Archive Afterlife is designed around a Gemma 2 integration, with a deterministic demo mode available when live inference is not configured. This makes the core experience accessible while keeping the model integration replaceable.

To me, open innovation is not just about using an open model. It is about building systems that other people can understand, adapt, and carry forward.

🕯️ What I Learned

Building Archive Afterlife reinforced an interesting idea: AI can be more than a conversational interface.

It can become a way to interact with technical history — provided that the experience makes room for evidence, uncertainty, and human judgment.

A legacy codebase is rarely just a collection of outdated files. It is also a record of the problems developers faced, the trade-offs they made, and the possibilities they explored.

Making that history easier to understand might help someone discover an idea worth saving.

🔮 What's Next?

I'd love to take Archive Afterlife further by adding:

More robust retrieval across large repositories.
Deeper dependency and security analysis.
Better citation verification for generated answers.
More ways to export and preserve complete project archives.
A fully tested live Gemma inference workflow.

💬 Let's Talk

If you could resurrect one abandoned open-source project, which would you choose?

And more importantly, what would you ask its ghost?

Share your answers in the comments. Let's give forgotten ideas another life.

Built for Hacktoberfest 2026 — Open-Source AI Challenge, Week 4: Ghost in the Machine. 👻

Hacktoberfest #OpenSource #AI #Gemma #WebDev

# 🦥 SlothFlow: Do Less. Let Open-Source AI Handle the Friction.

Tanisha — Thu, 22 Oct 2026 16:14:14 +0000

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

🦥 SlothFlow: Do Less. Let Open-Source AI Handle the Friction.

What I Built

What if productivity wasn't about doing more, but about making everyday tasks require less effort?

That's the idea behind SlothFlow, a privacy-conscious AI suite built around the Slow and Steady philosophy for Hacktoberfest 2026.

Instead of creating another chatbot that gives you more things to read, I wanted to build tools that reduce the small, exhausting bits of everyday life: catching up on group chats, figuring out what to cook, organizing digital clutter, and winding down after a long day.

SlothFlow combines local heuristics and browser-native capabilities with open-weight AI inference where it adds value.

The result is a collection of five tools designed to help you conserve your energy for things that actually matter.

1. 🌙 Overnight Chatter Condenser

Ever wake up to hundreds of unread messages and feel like you've already had a full day?

The Chatter Condenser turns pasted chat logs into a concise, two-line summary, an actionable FOMO Verdict, and a filter for low-value debates.

The goal isn't to read every message. It's to understand what matters, identify anything requiring your attention, and get on with your morning.

2. 🥑 Lazy Fridge-to-Feast

Staring into the refrigerator and still having no idea what to eat is a surprisingly common problem.

This tool takes an ingredient or refrigerator image and helps turn available ingredients into low-effort meal suggestions. Its guiding principles are simple: fewer steps, minimal cleanup, and recipes designed around the infamous one-pan rule.

It can also suggest staple ingredients to consider on your next grocery run.

3. 🗂️ TidyDesk Procrastination Cleaner

Downloads folders have a remarkable ability to become digital junk drawers.

TidyDesk helps organize file information into sensible categories and generates a reviewable shell script for file organization. The goal is to make tidying a deliberate, manageable action instead of another task you keep postponing.

Generated scripts should always be reviewed before execution, especially when working with personal documents or financial records.

4. 🌧️ Offline Wind-Down & Procedural Soundscapes

Sometimes the most useful thing an AI tool can do is help you stop staring at a screen.

The Wind-Down Companion uses browser-native Web Audio synthesis to create procedural ambient soundscapes, including rain, wind, and campfire-inspired sounds, without requiring downloaded audio tracks.

It also includes relaxing bedtime narratives, browser text-to-speech, and a sleep timer with a gradual fade-out.

Its offline capabilities are especially useful here: once the application and required assets are available, supported sound-generation features can run without making model requests.

5. ✍️ Hacktoberfest DEV Submission Builder

Building a project is one challenge. Explaining its architecture, open-source choices, and impact is another.

The Submission Builder generates Markdown drafts that describe the project and connect its design decisions to the challenge prompt.

It helps turn implementation details into a structured project story, while the final post still needs a human review to ensure that every claim matches the code.

Demo Snippet:

Explore the five modules and try the features with sample inputs before using personal data.

Code

💻 GitHub Repository: https://github.com/Tanishaaaaaaa/slothAI

The repository contains the source code and project documentation.

How I Built It

SlothFlow was developed using a browser-based AI development workflow, with Gemini assisting in generating and refining the application.

The architecture combines:

React and TypeScript for the application interface and modular components.
Browser-native Web Audio APIs for procedural sound generation.
Local heuristics for lightweight task processing without depending on remote model inference.
Gemma open-weight model integration for tasks that benefit from language-model reasoning, subject to the configured inference environment.
Browser-based file handling and generated shell scripts for reviewable organization workflows.

The project follows a hybrid approach: use lightweight local capabilities when they are sufficient, and use model inference when a more capable response is needed.

This distinction matters. Open-weight models can be self-hosted, but a hosted inference endpoint still requires an internet connection. Likewise, offline functionality depends on which application assets and capabilities are already available locally.

Why Open Innovation Matters

Open innovation matters because developers should have meaningful choices about how AI works, where data is processed, and how systems can be adapted.

For SlothFlow, that means three things.

1. Choice over the model

Open-weight models such as Gemma give developers more flexibility to experiment with model behavior, evaluate alternatives, and potentially self-host inference rather than relying exclusively on a proprietary hosted model.

2. Local capabilities where they make sense

Not every task needs an LLM. Simple heuristics can handle lightweight operations, while procedural audio can be generated directly in the browser. These approaches reduce unnecessary model calls and can continue working without a live inference service when their dependencies are available locally.

3. More control over personal data

Chat logs, refrigerator photos, and personal documents can contain sensitive information. Keeping processing local where practical reduces unnecessary data transfers. Any remote inference path must be disclosed clearly so users understand when their inputs leave the device.

Open-source AI isn't automatically private, free, or offline. Those properties depend on the implementation and deployment choices. SlothFlow explores how combining open-weight models with local processing can give developers more control over those choices.

Challenges I Ran Into

The biggest design challenge was balancing a useful AI experience with a lightweight, low-friction application.

A hybrid architecture introduces trade-offs: local heuristics are fast and can work offline, but are less flexible than language models. Hosted inference can produce richer results, but introduces connectivity, latency, and data-handling considerations.

Another challenge is making productivity features genuinely useful without pretending the software can safely perform every action automatically. For example, a generated file-organization script should remain reviewable rather than silently moving or deleting important files.

These trade-offs shaped SlothFlow's focus on small, understandable actions rather than automation for its own sake.

What's Next?

I'd like to explore more robust local inference options, configurable privacy controls, better validation of AI-generated recommendations, and additional ways to reduce repetitive everyday work.

The longer-term goal is simple: software that quietly removes friction instead of demanding more attention.

Final Thoughts

Hacktoberfest's Slow and Steady theme was a reminder that useful software doesn't always need to be ambitious in the loudest possible way.

Sometimes, the best tool is the one that helps you read fewer messages, wash fewer dishes, organize fewer things manually, or finally get some rest.

Build thoughtfully. Automate the boring bits. Embrace your inner sloth. 🦥

Hacktoberfest #OpenSourceAI #Gemma #AI #WebDev

RELAY: What If AI Could Hand Over Knowledge Without Losing the Context? 🔗🤖

Tanisha — Sat, 17 Oct 2026 11:36:50 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

Have you ever tried to hand over a task to someone else, only to realize that all the important details exist in your head, scattered messages, random notes, and old conversations?

Now imagine an AI system that could bring those details together, distinguish facts from uncertainty, and prepare a useful handoff without pretending to know things it doesn't.

That's the idea behind RELAY — Personal Knowledge Handoff AI, a project I built to explore a more reliable way of transferring knowledge.

RELAY takes messy personal knowledge, such as messages, notes, receipts, images, and voice notes, and organizes it into a temporary, evidence-backed handoff.

Instead of simply generating a summary, the project focuses on questions that matter when someone else needs to act on the information:

Evidence-backed answers: Can we connect an answer to the information that supports it?
Temporal conflict detection: What happens when two pieces of information disagree or refer to different points in time?
Explicit uncertainty: Can the system acknowledge what it doesn't know instead of presenting guesses as facts?
Source provenance: Where did a particular piece of information come from?
Temporary handoffs: How can we transfer the context someone needs without treating every detail as permanent knowledge?

The goal is simple: make knowledge easier to transfer while preserving the context behind it.

Why I Built It

I wanted to explore a problem that goes beyond generating answers with AI.

In many real-world situations, the challenge isn't a lack of information. It's that the information is fragmented, outdated, contradictory, or difficult for another person to reconstruct.

A generic summary can miss these distinctions. A confident AI-generated answer can also be misleading when the underlying evidence is incomplete.

RELAY explores a different approach: the handoff should preserve evidence and uncertainty, not just produce a polished summary.

This project helped me think more deeply about how AI systems can be designed around trust, traceability, and practical usefulness rather than generation alone.

Demo

🎥 Watch the demo: https://youtu.be/5DhEMq-5jpc

💻 Explore the source code: https://github.com/Tanishaaaaaaa/relay-ai-handoff

The key idea behind RELAY is that the answer itself isn't the whole story. Being able to understand where information came from, identify conflicting details, and recognize uncertainty is equally important.

Partner Technologies

RELAY explores an open-weight, local-first AI architecture alongside an application designed to organize information and build evidence-backed handoffs.

1. Open-weight AI

The project explores using open-weight models for knowledge processing. This approach offers flexibility in how AI inference can be configured and deployed, including the possibility of running models locally.

2. Evidence and provenance

An important part of the project is connecting extracted information to its supporting sources. This makes the handoff more useful than a standalone generated summary and helps preserve the context behind individual claims.

3. Conflict detection and uncertainty

Information can change over time, and different sources can disagree. RELAY's design explicitly considers temporal conflicts and uncertainty instead of assuming every extracted fact is equally reliable.

4. Local-first architecture

The project explores a more flexible architecture in which local AI inference can be an option. This is especially interesting when considering the control developers may want over their AI infrastructure and data workflows.

The broader lesson for me was that choosing an AI model is only one part of building a useful AI application. The surrounding system — including evidence handling, conflict detection, and uncertainty — matters just as much.

For the MLH partner-technology requirement, I would identify the specific partner product and explain its actual implementation here before submitting. I don't want to claim an integration that the project hasn't verified.

Hackathon Experience

Building projects around AI is a great reminder that an interesting idea is only the beginning.

The real work comes from turning that idea into a concrete problem, making architectural decisions, experimenting with tools, and deciding which details deserve the most attention.

While working on RELAY, I kept coming back to one question:

What makes an AI system useful enough to trust with a real task?

For me, the answer isn't just a better model. It's a system that can explain its answers, preserve the source of its information, recognize contradictions, and be honest about what remains unknown.

That perspective shaped how I approached the project and what I wanted to learn from building it.

I'm excited to keep exploring AI systems that solve practical problems while taking reliability and context seriously.

Thanks to MLH and DEV for bringing builders together and creating opportunities to share projects, learn, and experiment! 🚀

If you're interested in knowledge handoffs, evidence-backed AI, or open-weight models, I'd love for you to check out RELAY and share your thoughts.

🔗 GitHub: https://github.com/Tanishaaaaaaa/relay-ai-handoff

🎥 Demo: https://youtu.be/5DhEMq-5jpc

DukaanDraft

Tanisha — Thu, 15 Oct 2026 16:57:09 +0000

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

What I Built

🛍️ DukaanDraft — Your products. Better words. More sales.

Small business owners often spend more time writing product descriptions than actually selling their products. Creating separate captions for Instagram, descriptions for WhatsApp catalogues, promotional messages, and answers to customer questions can quickly become repetitive.

I built DukaanDraft, an AI-powered listing assistant that helps small Indian sellers turn basic product details into a ready-to-use marketing pack.

The idea is simple: enter your product name, price, features, preferred platform, language, and tone. DukaanDraft generates:

📸 Instagram captions with relevant hashtags
💬 WhatsApp catalogue descriptions
✨ Three alternative opening hooks
❓ Frequently asked questions based on the supplied product facts
📣 A short promotional message

It supports English, Hindi, and Hinglish, with different tones for different kinds of businesses.

The goal is to help independent sellers, home businesses, jewellery makers, and small online stores spend less time writing copy and more time running their businesses.

Demo

Try DukaanDraft:
For the demo, I used an organic Kachi Ghani yellow mustard oil listing priced at ₹349 and asked the model to generate WhatsApp marketing copy in Hinglish.

The generated content preserved the supplied product details, including the Rajasthan yellow mustard seeds, traditional wooden kohlu extraction below 45°C, and BPA-free UV-protected amber bottle.

It also handled missing information correctly. When asked about cash on delivery and shipping timelines, it indicated that the seller needed to confirm those details rather than inventing an answer.

Code

GitHub repository: https://github.com/Tanishaaaaaaa/dukaan-draft

The project includes the frontend, backend generation endpoint, model integration, and product-copy generation workflow.

How I Built It

I wanted to keep DukaanDraft small enough to build quickly but useful enough to solve a real business problem.

The application uses:

React and Vite for the user interface.
Node.js and Express for the backend API.
Google's open-weight Gemma model for product-copy generation.
Google's Gen AI SDK to send prompts to the model.
Environment-based secret management to keep API credentials out of frontend code.

The frontend collects product details and sends them to a backend /api/generate endpoint. The backend constructs a prompt using the seller's inputs, calls the configured Gemma model, and returns the generated content to the interface.

The application is configured to use gemma-4-26b-a4b-it. The generation flow was tested end to end, with a reported successful response and approximately 45 seconds of inference latency during the test.

I also added error handling with retries for transient upstream failures, individual copy actions for generated FAQs, and responsive layouts for mobile screens.

One important design decision was to ground the output in the seller's actual product information. Marketing copy is useful only when it remains trustworthy. DukaanDraft should not invent prices, product attributes, shipping promises, or answers to questions the seller has not addressed.

Why Does Open Innovation Matter?

For a small side hustle, the economics of AI matter.

A seller generating a handful of product listings should not need an expensive, complicated software stack just to write product descriptions.

Using an open-weight model such as Gemma gives developers the flexibility to experiment with different model configurations, tailor prompts to a specific audience, and explore different inference setups as a product grows.

For DukaanDraft, this creates several opportunities:

1. Building for a specific audience

Generic writing assistants are designed for a broad range of tasks. DukaanDraft focuses on the needs of small sellers, including platform-specific copy, INR pricing, and conversational Hinglish marketing.

2. More control over the AI workflow

The generation prompts and output structure can be adapted to the seller's business without rebuilding the application around a proprietary, closed model.

3. Flexibility in deployment and cost

Open-weight models provide options for hosted inference or, where supported hardware and model requirements permit, self-hosted inference. Comparing these options could help reduce costs as usage grows and give the application more control over its infrastructure.

4. Building without unnecessary complexity

I could focus on a narrow, useful workflow instead of building a large AI platform. The model performs the language-generation task, while the application handles product inputs, formatting, and copying the results.

There are trade-offs, too. Hosted inference still depends on provider availability, latency, and applicable usage limits. Running an open-weight model does not automatically make inference free or guarantee that customer data remains private.

For this version, I used hosted Gemma inference. A future version could explore local inference for sellers who need greater control over their data.

To me, open innovation means having more choices about how an AI product is built, customized, and operated.

My Agent Session

The project was developed and tested with an AI-assisted coding workflow in Google AI Studio.

I used iterative prompts to build the application, integrate Gemma, and audit the connection between the frontend and backend. The audit also covered product-fact preservation, API error handling, copy actions, and mobile responsiveness.

I did not save a shareable DevRelay session for this build, so I am not including a session link.

Prize Categories

Gemma — Best Use of Gemma: DukaanDraft uses Gemma as its configured product-copy generation model.
Overall Hacktoberfest Open-Source AI Challenge: A focused AI product designed around a real customer problem and a plausible path to monetization.

What's Next?

The next step is to put DukaanDraft in front of real small-business owners and learn whether it genuinely saves them time.

I'd especially like to test it with independent sellers who manage their own Instagram and WhatsApp catalogues. Their feedback will help determine which features are worth building next and whether a paid tier for generating listings in batches makes sense.

Because a useful side hustle should start with a real problem, not just an interesting model.

Thanks for checking out DukaanDraft! 💗

TouchGrass Quest Lab 🌿: Can Gemma Turn a Short Break Into an Outdoor Adventure?

Tanisha — Sun, 11 Oct 2026 06:52:16 +0000

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

What I Built

What if we used AI to help us spend less time on our screens?

For Hacktoberfest Week 1, I explored that idea through TouchGrass Quest Lab, a small experiment using Gemma to generate personalized outdoor quests.

The idea is simple: tell the model how much time you have, what kind of activity interests you, and what environment you're in. It generates a short mission that encourages you to step outside and notice the world around you.

Instead of suggesting another app to scroll through, the goal is to give you something to do that doesn't require looking at your phone.

I explored three scenarios:

The Concrete Jungle Safari: Observe tree branches, listen for natural sounds, and discover plants growing in unexpected places.

The Urban Leaf Detective: Compare leaf shapes, observe climbing plants, and notice the colors of flowers.

Garden Glimpse: Adapt plant-observation activities for someone with only five minutes and no desire to touch plants.

The most interesting part was the last scenario. When I asked Gemma to revise an existing quest for a more restrictive setting, it changed the activities and explained why it had made those changes.

This is currently a prompt-based experiment rather than a finished application. I wanted to investigate the model's ability to generate useful activities and respond to constraints before attempting a larger implementation.

Demo

The experiment was conducted using Gemma through Google AI Studio.

Demo artifacts: I'll include screenshots of the original quests and the revised Garden Glimpse response to show the actual model outputs.

Code

The experiment documentation, prompts, recorded outputs, and evaluation notes are available in my GitHub repository:

Tanishaaaaaaa / touchgrass-quest-lab

TouchGrass Quest Lab 🌿

A small prompt-based experiment with Gemma in Google AI Studio

Hacktoberfest 2026 — Week 1 theme: “Touch Grass”

TouchGrass Quest Lab explores whether an open-weight language model can generate short, safe, phone-free outdoor activities and revise them when the user's constraints change.

Scope note: This repository documents a manual experiment conducted through Gemma in Google AI Studio. It is not a standalone application, does not run inference locally, and does not claim offline operation. Check the challenge rules or ask the organizers whether a prompt-and-evaluation artifact meets the “build something” requirement before treating this as an eligible submission.

Research question

Can Gemma generate practical outdoor quests and adapt them when time, environment, or activity constraints change?

Setup and reproducibility

Interface: Google AI Studio
Model family: Gemma
Inference: hosted through Google AI Studio
Runtime, model version, generation settings, and date/time should be added by the author if…

View on GitHub

The repository documents the prompts used, the observed model responses, and the limitations identified during testing.

How I Built It

I used Gemma through Google AI Studio and designed a series of structured prompts to explore three questions:

Can the model generate concrete outdoor activities rather than generic wellness advice?

Does it adapt its suggestions when the activity preference changes?

Can it revise a quest when the available time and environment become more restrictive?

Each prompt specified the activity preference, time available, setting, equipment constraints, and safety requirements.

I then reviewed the responses qualitatively, looking at relevance, actionability, constraint adherence, safety, and whether the activities could be completed without using a phone.

One limitation became clear: the model sometimes generated relevant activities without fully satisfying the request. For example, a gardening prompt produced plant-observation tasks rather than activities involving gardening itself. The revised five-minute quest also failed to explicitly repeat the time limit.

These small mismatches were useful findings. They reinforced the importance of evaluating AI-generated outputs instead of assuming that a plausible answer is necessarily a correct one.

Why Does Open Innovation Matter?

I chose Gemma because open-weight models offer developers opportunities to experiment with model behavior and, depending on the model's license and deployment setup, choose how inference is run or adapt a model to a particular task.

For a future version of TouchGrass Quest Lab, local inference could be interesting. It could potentially let users generate quests without sending their prompts to a remote inference service, and possibly support offline use once the required model and software are installed.

However, this experiment used hosted inference through Google AI Studio. I haven't tested local execution, offline functionality, fine-tuning, or a comparison against a closed model.

For me, open innovation matters because it makes those alternative approaches possible to explore. It also encourages developers to understand the trade-offs instead of treating an AI model as an opaque API.

I see TouchGrass Quest Lab as an early experiment in that direction: a small idea, a real model, observable outputs, and clear limitations.

My Agent Session

I used Google AI Studio for the experiment. I haven't saved a DevRelay agent session for this work, so there isn't a session link to share.

The prompts and recorded outputs are documented in the repository instead.

Prize Categories

Potential category: Gemma — Best Use of Gemma

Gemma was the model used in this experiment. However, given that this is currently a prompt-based evaluation rather than a complete application, I would verify eligibility with the challenge organizers before claiming this as a qualifying partner-category entry.

The goal of TouchGrass Quest Lab is straightforward: explore whether AI can help people spend a little less time on their phones and a little more time noticing what's around them.

Sometimes, the best interaction with technology is the one that encourages you to put it away.

devchallenge #hf26challenge

The Person Who Knows Where Everything Is — So I Built an AI That Can Hand It Over

Tanisha — Fri, 02 Oct 2026 16:49:46 +0000

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

What I Built

There is usually one person in every household or friend group who somehow knows everything.

Not everything in a dramatic way.

Just the oddly specific things everyone eventually asks them:

“Where is the spare key?”

“Who fixed the washing machine last time?”

“What do I do when the Wi-Fi stops working?”

“When is the purifier due for service?”

“Which plumber should I call?”

The problem is that this knowledge rarely lives in one place.

Some of it is in WhatsApp messages.
Some is in screenshots.
Some is buried in PDFs and receipts.
Some exists as voice notes.
And some of it only exists in that one person's memory.

That person was the inspiration for RELAY.

RELAY is a personal knowledge handoff system that turns scattered information into a temporary, evidence-backed handoff that someone else can actually use.

Instead of asking the person who "knows everything" to sit down and manually explain it all, RELAY reconstructs the important context and organizes it into:

What you need to know
Who you need to contact
What needs attention
What changed recently
What is uncertain
Where each important fact came from

The key design principle is simple:

RELAY should never sound more certain than the evidence allows.

For example, if an old message contains a Wi-Fi password but a newer message says the password was changed, RELAY doesn't guess the new one.

It says:

I don't know the current Wi-Fi password.

An older password exists, but a later source says it was changed. No replacement was found.

That behaviour is intentional.

I wanted to build something that doesn't just remember information, but understands when information is old, conflicting, or incomplete.

Demo

Demo Video: https://youtu.be/5DhEMq-5jpc

The most important interaction is not the answer itself.

It is being able to ask:

“Why do you think that?”

and see the source that supports it.

Code

GitHub Repository: https://github.com/Tanishaaaaaaa/relay-ai-handoff/tree/main

How I Built It

The architecture is deliberately split into two parts:

reconstruction and handoff.

The first stage takes messy information and turns it into structured facts.

The second stage decides what belongs in the actual handoff.

Messages / PDFs / Images / Voice Notes
                  ↓
             Ingestion
                  ↓
        Open-weight AI / extraction
                  ↓
          Structured facts
                  ↓
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    Sources    Timeline    Relations
       └──────────┼──────────┘
                  ↓
       Conflict + freshness checks
                  ↓
         Evidence-backed state
                  ↓
            Handoff Builder
                  ↓
          Temporary handoff

Open-source AI

RELAY is designed around Gemma, an open-weight model that can be run locally through Ollama.

The repository includes an Ollama adapter in:

server/ollama.js

The model is instructed to answer only from the supplied reconstructed context and to explicitly say when the available evidence is insufficient.

The system can therefore work in two modes:

Demo/evidence-engine mode

Useful for running the project immediately without requiring local model inference.

Local Gemma mode

The /api/ask endpoint can route questions through a locally running Gemma model via Ollama.

For example:

User question
     ↓
RELAY API
     ↓
Local Gemma
     ↓
Evidence-grounded answer

The model is not treated as the permanent source of truth.

Instead, the application keeps the evidence and provenance separate from the model layer.

That makes the model replaceable and the reasoning workflow inspectable.

Backend

The backend is a Node.js + Express API.

It exposes endpoints including:

GET  /api/health
GET  /api/handoff
GET  /api/facts
GET  /api/conflicts
GET  /api/sources

POST /api/ask
POST /api/handoff/build
POST /api/ingest

Evidence and conflict handling

One of the most important parts of RELAY is that facts carry context around them.

A fact isn't just:

{
  "value": "Suresh"
}

It also has information such as:

{
  "value": "Suresh",
  "source": "maintenance-chat.txt",
  "updated": "2026-09-02",
  "confidence": 0.89
}

This lets RELAY surface situations like:

Plumber contact changed

Older: Rakesh

Newer: Suresh

Reason: A newer message explicitly replaces the older contact.

Or:

Wi-Fi password is stale

Older password: Found

New password: Unknown

Reason: A later message says the password changed, but the replacement was not found.

That is much more useful than simply retrieving every matching message.

Why Does Open Innovation Matter?

The information RELAY is designed to work with can be extremely personal.

It can include:

private conversations
phone numbers
receipts
addresses
photographs
household routines
personal notes
voice recordings

I didn't want the product to require all of that information to be sent to a remote black-box AI service just to answer a simple question.

Using an open-weight model gives me another option:

Run the intelligence closer to the data.

With a local Gemma + Ollama setup, the model can run on the user's own machine.

That matters for this project for three reasons.

Privacy

Sensitive personal information can stay local.

Control

The model can be swapped, tested, evaluated, or replaced without redesigning the whole application.

Transparency

The AI layer doesn't have to be the only place where reasoning happens. RELAY can keep evidence, source provenance, and conflict information as first-class parts of the system.

For this particular problem, open AI isn't just a checkbox.

The privacy requirement is part of the product itself.

Prize Categories

Best Use of Gemma

RELAY is designed around Gemma as the open-weight model layer, with local inference supported through Ollama.

The idea behind RELAY started with something very ordinary:

There is always someone everyone depends on because they remember the little things.

The goal wasn't to make that person remember more.

It was to make it easier for them to hand over what they already know.

And maybe that is a better way to think about AI memory:

Not keeping everything forever.

Keeping the right context until somebody else can carry it.

devchallenge #weekendchallenge #hf26challenge #hacktoberfest #opensource #ai #gemma #ollama

# 🛰️ Problem Radar – Transforming Frustrations into Startups

Tanisha — Wed, 25 Mar 2026 16:26:05 +0000

This is a submission for the Notion MCP Challenge

🚀 What I Built

Problem Radar is an innovation engine that converts everyday frustrations into startup-ready ideas in seconds.

Instead of just brainstorming, it validates, structures, and prepares your idea for execution—all while syncing everything seamlessly into Notion.

Think of it as your personal hackathon co-founder that never sleeps ⚡

💡 What makes it special?

Turns vague problems into clear startup concepts
Generates technical + business insights instantly
Provides a ready-to-execute roadmap
Syncs everything into a beautiful, structured Notion workspace

💻 Show us the code

🔗 GitHub Repo:
https://github.com/Tanishaaaaaaa/problem-radar-ai

🧠 How I Used Notion MCP

Notion MCP is the core superpower of Problem Radar.

🔗 Seamless Auto-Sync

Every generated idea is instantly pushed to Notion using the Notion SDK. No manual effort. No copy-paste.

📄 Smart Page Generation

Each project automatically creates a structured Notion page with:

Problem Statement
Solution Idea
Target Users
Tech Stack
Elevator Pitch
Market Viability Score

📊 Execution-Ready Workflow

Problem Radar doesn’t stop at ideation. It creates a Sprint 1 Kanban board directly inside Notion, giving users an immediate development roadmap.

⚡ What this unlocks

Turns Notion into a live startup builder
Bridges idea → validation → execution
Eliminates friction between thinking and building

📡 Key Features

🛰️ Radar Visualization

A real-time animated interface that simulates scanning for opportunities—bringing the entire concept to life.

🧠 Intelligent Hackathon Engine

Generates:

Startup names
Problem & solution breakdown
Target audience
Tech stack
Elevator pitch

All powered by a fast, local logic engine (no AI dependency) for speed and privacy.

📈 Execution & Viability Dashboard

Market Viability Score
Monetization strategies
Team composition suggestions

📋 Notion Superpower

Auto-generated project pages
Pre-filled structured content
Built-in Kanban board

🛠️ Tech Stack

Frontend: Next.js (App Router), React, Tailwind CSS
Styling: Glassmorphism + custom animations
Backend: Next.js Edge API Routes
Integration: Notion SDK (@notionhq/client)
Core Engine: Local logic-based system

⚙️ Setup & Installation

git clone https://github.com/Tanishaaaaaaa/NotionAIChallenge.git
cd NotionAIChallenge
npm install

Create .env.local:

NOTION_API_KEY=your_notion_token
NOTION_DATABASE_ID=your_database_id

Run the app:

npm run dev

🏆 Why This Could Win

Problem Radar is not just a project—it’s a startup-generation system.

It combines:

⚡ Speed (instant idea generation)
📊 Structure (execution-ready outputs)
🧠 Intelligence (deep analysis engine)
🔗 Integration (Notion as a command center)

👉 The result:
A tool that doesn’t just inspire ideas—it builds them into reality.

🎯 Final Thought

Most people have ideas.
Very few know how to execute them.

Problem Radar bridges that gap.

# 🛰️ I Built an App That Turns Daily Frustrations Into Hackathon Ideas (and It Might Replace Brainstorming 👀)

Tanisha — Fri, 20 Mar 2026 18:23:46 +0000

You know that moment in every hackathon where your team just sits there like:

“So… what should we build?”

Yeah. That.

I got tired of it.

So I built something to fix it.

🚀 Meet: Problem Radar

An app that takes your everyday frustrations and turns them into:

💡 A startup idea
🛠️ A tech stack
🎯 Target users
🎤 A pitch
📋 And even a build plan

All in seconds.

🧠 The Idea

Every day, we complain about things like:

“Parking in cities is impossible”
“Food delivery takes forever”
“Attendance systems are outdated”

👉 Hidden inside those complaints are startup ideas

Problem Radar just… extracts them.

⚙️ How It Works

You type something like:

Finding parking in Bangalore is impossible

And the app generates:

Problem Statement
Target Users
Severity Score
Solution Idea
Tech Stack
Elevator Pitch

Then…

👉 It auto-saves everything into Notion as a ready-to-build project

🔥 The Cool Part (Notion Integration)

This is where it gets interesting.

Instead of just showing output, the app:

Creates a structured page in Notion
Adds problem + solution
Suggests tech stack
Generates a Sprint 1 plan

So your idea doesn’t just sit there…

👉 It becomes something you can actually start building immediately

🧩 Features That I’m Proud Of

📡 Radar Visualization

A live “problem radar” UI that makes the whole experience feel like you're scanning for opportunities.

🧠 Logic-Based Engine (No AI API)

Instead of relying on external AI APIs, I built a local logic engine that:

detects users
estimates severity
suggests solutions

👉 Faster, cheaper, and works offline.

📈 Viability Dashboard

Market score
Monetization ideas
Team suggestions

🛠️ Tech Stack

Next.js (App Router)
React
Tailwind CSS
Notion SDK
Custom logic engine

🤯 Why This Matters

Most tools help you build faster.

This helps you decide:

what is worth building in the first place

🏆 Built for the Notion x MLH Challenge

The goal was to create a system where:

AI (or logic) + Notion = superpowers

So I turned Notion into:
👉 a live database of real-world problems + solutions

👀 What’s Next?

I’m thinking of adding:

Real-time problem scraping (Reddit, reviews, etc.)
Team collaboration
“Trending problems” feed

💬 Question for you

If this existed…

👉 Would you use it before your next hackathon?

🔗 GitHub Repo

Tanishaaaaaaa / NotionAIChallenge

I built a system where Notion becomes your problem-solving brain, and AI continuously feeds it with real-world opportunities.

🛰️ Problem Radar - Transforming Frustrations into Startups

Problem Radar is a powerful innovation engine designed to bridge the gap between real-world pain points and actionable technical solutions. It empowers hackers and entrepreneurs to instantly validate ideas, draft technical specifications, and generate a clear roadmap for execution—all within a seamless, premium interface synced directly to Notion.

🚀 Key Features

📡 The Radar Visualization

A high-impact, real-time animation that brings the "Problem Radar" concept to life. It serves as your digital sentinel, constantly scanning for opportunities in every frustration.

🧠 Intelligent Hackathon Engine

Built with a sophisticated local logic engine, Problem Radar performs deep analysis on your inputs to generate:

Dynamic Startup Titles: Unique, catchy branding for your project.
Problem & Solution Synthesis: Clearly defined problem statements and action-driven solutions.
Target Audience Identification: Precision mapping of who your solution serves.
Tech Stack Recommendations: Tailored technology profiles optimized…

View on GitHub

If you made it this far — thanks 🙌
Would love feedback from fellow builders!

# 🤖 I Asked AI to Plan My Day… It Immediately Judged My Life

Tanisha — Tue, 17 Mar 2026 16:13:50 +0000

Artificial Intelligence is supposed to make our lives more productive.

So naturally, I thought:

“What if AI planned my entire day?”

Big mistake.

🧠 Step 1: The Plan

I asked the AI assistant:

“Create a productive schedule for my day.”

It responded instantly with something terrifyingly organized.

6:00 AM — Wake up  
6:15 AM — Meditation  
6:45 AM — Exercise  
7:30 AM — Healthy breakfast  
8:00 AM — Deep focused work

Meanwhile my real schedule looked like this:

8:47 AM — Wake up in confusion  
8:49 AM — Check phone  
9:20 AM — Still checking phone  
9:45 AM — Panic about productivity

We were already off to a great start.

☕ Step 2: AI Suggests “Healthy Habits”

AI suggested I drink lemon water in the morning.

I drank coffee instead.

Three cups.

The AI did not include “existential caffeine dependency” in its plan.

Missed opportunity.

📅 Step 3: “Deep Work Session”

According to the schedule:

8:00–11:00 AM: Deep work.

Reality:

8:03 — open laptop  
8:04 — check email  
8:09 — check news  
8:13 — check messages  
8:21 — watch one YouTube video

The YouTube video was titled:

“How to stop procrastinating.”

I watched three.

🧘 Step 4: AI Recommended Mindfulness

The AI suggested a 10-minute meditation break.

Instead I did a 10-minute staring-at-the-screen break.

Technically still mindfulness.

Just… aggressive mindfulness.

🍎 Step 5: Healthy Lunch

The AI recommended:

“Balanced nutrition with vegetables and lean protein.”

I ordered food.

The delivery app described it as:

“Chef’s special comfort meal.”

Which roughly translates to:

“Calories with extra calories.”

🧠 Step 6: Evening Reflection

The AI suggested ending the day by reflecting on accomplishments.

So I asked myself:

What did I achieve today?

answered two emails
opened 17 browser tabs
learned absolutely nothing useful on the internet

Progress.

🤖 What AI Taught Me About Productivity

After one day of following an AI schedule, I learned something important.

AI assumes humans behave like perfectly optimized machines.

But humans are more like:

80% chaos
10% coffee
10% actually doing things

And somehow…

it still works.

Final Thought

AI might help us organize our lives.

But until AI can handle:

procrastination
random curiosity
and late-night snack decisions

Human productivity will remain beautifully unpredictable.

❤️ If your daily routine also looks nothing like your productivity plan… you’re not alone.

# When Our AI Flood Prediction System Broke Because of Bad Data — and How We Fixed It 🌧️🛡️

Tanisha — Thu, 12 Mar 2026 13:57:32 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

The Moment Everything Broke

It was the middle of a hackathon.

Our AI model was ready.
The dashboard looked beautiful.
The architecture was solid.

But our system had one fatal flaw.

It had no reliable data.

And without data, our flood prediction platform was useless.

The Idea: Build an AI Guardian for Floods

Our team built StormShield AI, a real-time flood prediction and civic alert platform designed for Montgomery, Alabama.

The goal was simple:

Predict flood risks before they happen and alert citizens early.

The system combined:

Real-time environmental data
Machine learning forecasting
Generative AI alerts
An interactive dashboard

In theory, it was powerful.

But in practice, something kept breaking.

The Hidden Enemy of AI Projects

People think building AI systems is about models.

But the real challenge is something else:

Data pipelines.

StormShield depended on several live data sources:

USGS stream gauge data
NOAA weather alerts
Additional environmental signals

Some sources had APIs.

Others didn’t.

For those missing APIs, we turned to Bright Data web scraping.

That’s when the real problems began.

When Scraping Started Failing

The Bright Data scraping pipeline started behaving unpredictably.

We ran into multiple issues:

• Dynamic websites loading content with JavaScript
• Inconsistent HTML structures
• Rate limiting during scraping
• Partial or delayed responses

The result?

Our real-time dashboard would randomly stop updating.

Which meant our prediction engine stopped working too.

The Turning Point: Rethinking the Architecture

Instead of forcing scraping to work perfectly, we redesigned the pipeline.

We switched to a hybrid ingestion system.

Priority 1: Official APIs

We prioritized structured data from:

USGS Water Services API
NOAA/NWS Alerts

These became the backbone of our data pipeline.

Priority 2: Scraping as a Backup

Bright Data scraping became a fallback enrichment layer.

This meant scraping failures no longer broke the system.

Priority 3: Background Data Scheduler

We implemented APScheduler jobs that:

continuously poll data
cache responses
smooth noisy readings
retry failures

This made our system fault tolerant.

The Moment the Dashboard Came Alive

After hours of debugging…

The dashboard suddenly updated.

Live water levels appeared.

Prediction graphs began moving.

Alert statuses started changing dynamically.

Our system was finally working end-to-end.

That moment felt like magic.

What We Built: StormShield AI 🛡️

StormShield AI is a real-time flood prediction and civic alert system designed to help communities respond to dangerous weather events faster.

Key Capabilities

🌊 Real-Time Data Ingestion

Streams water-level telemetry from USGS gauges.

📈 Flood Prediction Engine

An XGBoost model predicts water levels 30 minutes ahead (T+30).

🚨 Smart Alert System

Status	Trigger	Meaning
🟢 GREEN	Normal conditions	Safe
🟡 YELLOW	Rapid rise detected	Prepare
🔴 RED	Flood stage predicted	Take action

🤖 Generative AI Alerts

Using Gemini 2.0 Flash, StormShield generates clear public safety messages that avoid panic but encourage action.

🗺️ Interactive Dashboard

Built using Streamlit, featuring:

live telemetry
predictive charts
flood zone maps
AI Q&A assistant

Tech Stack

Backend

Python
FastAPI
APScheduler
Uvicorn

Frontend

Streamlit
Plotly
Folium Maps

AI / ML

XGBoost forecasting
Gemini 2.0 Flash (alerts + RAG assistant)

Data Sources

USGS Water Services API
NOAA / NWS Alerts
Bright Data scraping

The Biggest Lesson I Learned

Before this project, I thought the hardest part of AI engineering was training models.

Now I know the truth.

The hardest part is getting reliable data into the system.

Building StormShield forced us to rethink architecture, redesign pipelines, and adapt under pressure.

And that’s the real engineering skill:

resilience when things break.

Why Experiences Like This Matter

Tech often looks polished from the outside.

But behind every working system are:

broken pipelines
failed experiments
late-night debugging sessions

StormShield AI reminded me that innovation doesn’t come from perfect plans.

It comes from figuring things out when nothing works at first.

Project Links

GitHub
[https://github.com/Tanishaaaaaaa/StormShield]

As a woman in tech, participating in hackathons like this reminds me that innovation often comes from diverse perspectives and collaborative problem solving.

🛡️ We Built an AI Flood Guardian in a Hackathon — Meet StormShield AI

Tanisha — Thu, 12 Mar 2026 13:06:39 +0000

🌧️⚡
Hackathons are chaotic.
You start with coffee ☕
You end with questionable sleep decisions, rapid-fire Git commits, and a lot of “wait… does this even run?” moments.
But sometimes something really cool comes out of that chaos.
For the World Wide Vibes Hackathon, our team OmniShield decided to build something that could actually help people during extreme weather events.
So we built:
🛡️ StormShield AI — a real-time flood prediction and civic alert system
A system that monitors water levels, predicts floods, and alerts citizens before things get dangerous.
And yes… we built it during a hackathon.

🌍 Live Demo
You can try the project here:
🚀 Live App (Render Deployment)
👉 https://stormshieldai-montgomery.streamlit.app/

🎥 Demo Video
We also recorded a walkthrough showing the system in action.
🎬 Watch the demo

Or watch directly here:
👉 https://www.youtube.com/watch?v=La_nr6mdPw0

🌊 The Problem
Flooding is one of the most common natural disasters worldwide.
The problem isn’t just detecting floods — it’s detecting them early enough to act.
Most traditional systems:
rely on static thresholds

provide delayed alerts

don’t explain what people should actually do

We wanted to build something smarter:
⚡ Real-time monitoring
🤖 AI-powered predictions
📢 clear public alerts

🛡️ Enter StormShield AI
StormShield acts like a digital guardian for the city.
It continuously monitors environmental data, predicts what might happen next, and informs citizens before flood conditions escalate.
Think of it as:
🚨 An AI-powered early warning system for floods
Built for Montgomery, Alabama.

🌟 Key Features
🌍 Real-Time Data Ingestion
StormShield constantly collects live environmental data from:
🌊 USGS stream gauge data

⛈ NOAA / NWS weather alerts

🌦 local weather telemetry

This keeps the system aware of changing flood conditions in real time.

🤖 Predictive Flood Forecasting
We trained a machine learning model using XGBoost on historical water-level data.
The model predicts:
🌊 water levels 30 minutes into the future (T+30)
That short prediction window can provide critical early warning time.

🚨 Smart Alerting Engine
StormShield automatically categorizes risk levels:
Status
Condition
Meaning
🟢 GREEN
Normal water level
Safe conditions
🟡 YELLOW
Rapid water rise
Prepare / caution
🔴 RED
Predicted flood stage
Immediate action

The system also monitors rate-of-rise, one of the earliest indicators of flash flooding.

✨ Generative AI Alerts (Gemini 2.0 Flash)
Raw flood data isn’t helpful for most people.
So we integrated Gemini 2.0 Flash to generate clear, calm public alerts.
Instead of confusing telemetry, people receive messages like:
“Water levels are rising rapidly near Sligo Creek. Residents should avoid low-lying roads and prepare for possible evacuation guidance.”
Helpful. Clear. Not panic-inducing.

💬 Ask StormShield AI
We also built a RAG-powered AI assistant.
Citizens can ask questions like:
“Is my neighborhood at risk?”

“Which roads are flooded?”

“Where are evacuation points?”

StormShield searches live system data and answers instantly.

📊 The Dashboard
We created a live interactive dashboard using Streamlit.
Features include:
📈 real-time water telemetry
🌊 predictive flood charts
🗺 interactive flood zone maps
📍 live sensor markers
And one of our favorite features:
🌳 Green Infrastructure Simulator
It estimates how many trees would be needed to reduce water runoff and flood risk.
Because sometimes the best flood defense is simply more trees.

⚙️ Tech Stack
Backend
🐍 Python

⚡ FastAPI

⏱ APScheduler

🚀 Uvicorn

Frontend
🎛 Streamlit

🗺 Folium (interactive maps)

📊 Plotly charts

AI / ML
🌳 XGBoost (time-series forecasting)

🤖 Gemini 2.0 Flash (alert generation + RAG chatbot)

Data Sources
🌊 USGS Water Services API

⛈ NOAA / NWS alerts

🌐 Bright Data

🏗️ Project Architecture
StormShield/
│
├── backend/
│ ├── ingestion/
│ ├── processing/
│ ├── prediction/
│ ├── alert/
│ ├── simulation/
│ └── query/
│
├── frontend/
│ ├── dashboard
│ ├── interactive maps
│ └── chatbot interface
│
└── data/
├── model weights
└── telemetry cache

🚀 Running the Project Locally
Clone the repo:
git clone https://github.com/Tanishaaaaaaa/StormShield.git
cd StormShield
Create environment:
python -m venv venv
source venv/bin/activate
Install dependencies:
pip install -r requirements.txt
Train the model:
python backend/modules/prediction/train.py
Run backend:
uvicorn backend.main:app --reload --port 8000
Run dashboard:
streamlit run frontend/app.py

🏆 Hackathon Context
This project was built for the World Wide Vibes Hackathon.
Goal:
Build an AI-powered civic application that can help communities respond to extreme weather events.
Team: OmniShield
Project: StormShield AI
Sometimes hackathon ideas stay as prototypes.
But occasionally they turn into real-world solutions.
StormShield might just be one of those.

💬 We’d Love Feedback
If you were building an AI-powered smart city platform, what would you add?
Better prediction models?
IoT sensors?
Automated evacuation planning?
Curious to hear ideas from the community.

The Day I Realized Most Microservices Should Have Been a Cron Job

Tanisha — Thu, 12 Mar 2026 12:55:06 +0000

Let me tell you a story about a system that had:
14 microservices

Kubernetes

message queues

observability dashboards

distributed tracing

CI/CD pipelines for each service

It looked beautiful.
It also did one simple thing.
Once a day.
At midnight.

The Problem
The system’s job was simple:
Pull data from an API

Process it

Store the results in a database

That’s it.
Yet somehow the architecture diagram looked like this:
API → Ingestion Service → Queue → Processing Service → Queue → Worker → Database
All running on Kubernetes.
With autoscaling.
For a job that ran once every 24 hours.

The Moment of Realization
During a debugging session someone asked:
“Why does this need three services?”
Silence.
Then someone said the sentence that changed everything:
“Could this just be… a cron job?”

The Architecture We Replaced It With
Before:
Kubernetes
├── ingestion-service
├── processing-service
├── worker-service
└── queue infrastructure
After:
cron → script → database
Lines of code dropped from ~4000 → ~300.
Infrastructure complexity dropped by about 90%.
Operational issues dropped to almost zero.

Why This Happens So Often
Developers love building distributed systems.
But many systems don’t actually need to be distributed.
What happens is usually this:
A simple system starts growing

Someone suggests microservices

The architecture becomes “future proof”

The future never actually arrives

Suddenly you have Kubernetes managing a workflow that could run inside a single Python script.

Microservices Are Great — When You Actually Need Them
Microservices solve real problems:
independent scaling

team autonomy

fault isolation

complex systems with many domains

But if your system:
runs once a day

processes a small dataset

is owned by one team

has a simple workflow

You probably don’t need microservices.
You might just need:
cron + script

The Hidden Cost of Over-Engineering
Every additional service adds:
deployment pipelines

monitoring dashboards

failure points

infrastructure cost

debugging complexity

When something breaks, you’re suddenly tracing requests across five services instead of reading one log file.

The Rule I Follow Now
Before building a distributed system, I ask one question:
Could this be solved by a cron job?
If the answer is yes…
Start there.
You can always add complexity later.
But removing it is much harder.

The Irony
The funny thing is that the simplest system often ends up being the most reliable one.
Because it has fewer things that can go wrong.
Sometimes the best architecture decision is simply not building more architecture.

Your Turn
Be honest.
Have you ever seen a system that looked like this?
Kubernetes + 10 services
…doing something that could have been solved with a cron job and 200 lines of code?
If yes, I want to hear that story 😄