DEV Community: Keerthana Sathyavada

Flash: Celebrating Laziness with Zootopia’s Favorite Sloth

Keerthana Sathyavada — Wed, 21 Oct 2026 07:03:19 +0000

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

🦥 Flash: The Sloth Who Outsmarted a Fox

Celebrating laziness through Disney’s favorite sloth — one automated task at a time.

ZPD Headquarters. 9:00 AM.

Nick Wilde: (leaning back in his chair, spinning a pen between his fingers) “Well, well, well. If it isn’t Officer Hopps. Still doing everything manually? Spreadsheets, browser searches, reports... Carrots, I thought rabbits were supposed to be fast.”

Judy Hopps: (without looking up from her screen) “And I thought foxes were supposed to be clever, Nick. Yet here you are, wasting everyone's time.”

Nick: “Ouch. Anyway, I've got a little challenge for you. Compile this week's expense report, check three websites, organize the evidence, and prepare a briefing. You've got five minutes.”

(He drops a mountain of files onto her desk.)

Nick: “Let's see if those famous rabbit reflexes can beat a fox who already finished his coffee.”

Judy: (examining the files calmly) “You know, Nick, speed isn't the same as intelligence. And doing everything yourself isn't the same as being productive.”

(She opens Flash.)

Judy: “Flash, prepare the expense spreadsheet, organize my notes, and research these websites. Keep the original evidence untouched.”

Flash Slothmore: (slowly raises his head, blinks twice, and smiles) “Absoooooo-lutely.”

Nick: “Wait. You're trusting a sloth with a deadline?”

Judy: “I'm trusting a system I've designed to do the repetitive work, with boundaries I've chosen and results I can verify.”

(A few moments later, the spreadsheet is formatted, the notes are organized, and the browser research is ready for review.)

Nick: (staring at the screen) “That's... not possible. I haven't even finished my second coffee.”

Judy: “Maybe next time, Nick, you'll spend less time showing off and more time thinking.”

Flash: (smiling at his completed task list) “Have... a... nice... day.”

Nick Wilde: 0. Judy Hopps: 1. Flash: still not in a hurry.

🦊 Lesson learned: Never underestimate a rabbit with a plan and a sloth with an automation pipeline.

What I Built

Meet Flash — a local-first AI desktop companion inspired by Flash Slothmore, the unforgettable DMV sloth from Disney's Zootopia.

Most AI assistants are designed to answer questions. Some can call tools. Flash takes the next step: it helps turn natural-language instructions into practical desktop actions, from creating office documents to organizing checklists and automating browser workflows.

The goal is simple: let AI handle the repetitive work while humans stay in control of the important decisions.

Flash is built around an open-weight language model running locally, native Windows automation, a web companion, and a cloud coordination layer.

Think of it as a tiny sloth-powered productivity department that never asks for a coffee break.

What can Flash do?

1. Control native Windows applications

Flash can launch applications and interact with supported Windows interfaces using Python automation tools, including pywinauto and Windows UI Automation.

It can handle tasks such as opening Notepad, entering dictated notes, and interacting with supported application controls. Instead of relying entirely on brittle screen coordinates, it can inspect accessible UI elements where supported.

2. Generate real office documents

Flash can create useful files directly in its local workspace:

.xlsx spreadsheets for expenses and other structured data.
.docx documents for notes and reports.
.pptx presentations for briefings and slide decks.

No need to start from a blank document and spend ten minutes formatting column headers. Flash is happy to do the boring bits.

3. Accept voice-driven tasks and checklists

The companion interface supports voice dictation and task management, making it easier to add groceries, capture reminders, and organize everyday chores.

Instead of manually typing a shopping list on a tiny phone keyboard, you can simply tell Flash what you need.

4. Automate browser workflows

Using Stagehand and Browserbase, Flash can interact with supported websites, observe page elements, perform actions, and extract information for research tasks.

This makes repetitive browser work easier to structure into reusable workflows instead of manually jumping between tabs.

5. Connect a mobile-friendly companion to a local agent

The web companion is hosted on Render, while a separate Python agent runs on the user's Windows machine.

A pairing flow connects the two components without giving the cloud coordinator direct access to the desktop.

The important distinction: Flash's local desktop automation is designed to run on the Windows machine. Cloud-hosted browser sessions, online voice services, and other external integrations still require their respective network connections.

Demo

🌐 Live Web Companion: https://flash-cloud-coordinator.onrender.com/

🛡️ Security Boundary & Architecture: https://flash-cloud-coordinator.onrender.com/about

🐙 Source Code: https://github.com/SK-Sathyavada-008/flash

Open the live companion to explore Flash's animated sloth interface, voice-dictation experience, and interactive demo.

The companion includes cursor eye-gaze tracking and idle animations that give Flash a little personality. You can also explore the pairing flow for connecting to the local PC agent.

A note about the demo: The hosted companion demonstrates the web experience. Actual native Windows automation requires the local agent to be installed and running on a compatible Windows machine.

How I Built It

Flash combines local AI inference, deterministic command handling, Windows automation, browser tooling, and a cloud-hosted web companion.

The architecture is intentionally split into three layers.

1. The architecture

flowchart TD
    A["Mobile / Web Companion"] --> B["Render Cloud Coordinator"]
    B -->|"Paired connection"| C["Local Windows Agent"]
    C --> D{"Command Router"}
    D -->|"Known commands"| E["Deterministic Fast Path"]
    D -->|"Natural language"| F["Ollama + Gemma 2:2B"]
    E --> G["Validated Task Execution"]
    F --> G
    G --> H["Windows UI Automation"]
    G --> I["Office File Generation"]
    G --> J["Local Checklists & Notes"]
    G --> K["Stagehand + Browserbase"]
    C --> L["Voice Output"]
    C --> M["Logging & Error Tracking"]

The key design choice is that the local agent is responsible for desktop actions. Render hosts the companion and coordination service; it does not need direct desktop privileges to serve the web application.

2. Local intelligence with Gemma 2:2B

Flash uses Google's Gemma 2:2B, an open-weight language model, through Ollama.

Rather than sending every command to a remote language-model API, Flash uses a hybrid approach:

Deterministic fast path: Recognizes supported, predictable commands such as opening an application.
Local model inference: Routes more ambiguous natural-language instructions to Gemma for intent interpretation and parameter extraction.
Structured output: Uses constrained instructions and JSON-oriented parsing to make model outputs easier to validate.
Fallback parsing: Provides a rule-based alternative for supported commands when Ollama is unavailable.

The fast path avoids the overhead of model inference for commands that do not need it. The local model handles the more flexible language-understanding work.

Gemma does not need to be the fastest model in the city. It needs to be useful, available locally, and predictable enough to fit into a carefully designed workflow.

3. Native Windows automation

Flash uses Python-based Windows automation, including pywinauto and Windows UI Automation, to interact with supported applications.

The local agent is responsible for:

Launching applications.
Interacting with accessible interface elements.
Entering text and executing supported actions.
Creating and organizing files in the local workspace.

Separating command interpretation from execution makes it easier to validate instructions before carrying them out.

A language model can interpret what a user wants, but the automation layer should determine which actions are actually supported.

4. Office file generation

Flash generates real files instead of merely describing how to create them.

Python document-generation libraries handle the structured output, including spreadsheets, Word documents, and presentations.

This is a useful example of why an AI application does not need to use a language model for everything. Gemma interprets the request; deterministic code handles the formatting and file creation.

The result is a practical combination of flexible language understanding and conventional software engineering.

5. Voice: ElevenLabs and offline fallback

Flash integrates ElevenLabs for neural text-to-speech, giving the companion a more expressive voice.

For supported local speech-output workflows, Windows SAPI through pyttsx3 provides an offline fallback.

This distinction matters: the local speech fallback can work without an internet connection, but ElevenLabs and other cloud services still depend on connectivity.

The result is a voice experience that can degrade gracefully instead of treating a network outage as the end of the world.

6. Browser automation with Stagehand and Browserbase

Flash integrates Stagehand's browser automation primitives — act, observe, and extract — with Browserbase-hosted browser sessions.

These tools can help Flash interact with websites, inspect page content, and extract relevant information.

The browser component is separate from the local Windows automation component. Because Browserbase runs browser sessions in the cloud, those workflows require network access and should be treated separately from local-only operations.

7. Render, MongoDB Atlas, and observability

The remaining infrastructure makes Flash easier to deploy and operate:

Render: Hosts the web companion and cloud coordination service.
MongoDB Atlas: Supports persistent storage for routines, checklists, and preferences, with local JSON fallback where configured.
Sentry: Supports error reporting and observability for troubleshooting agent operations.

Together, these services make Flash more than a local script. They provide a path toward a usable companion with a web interface, persistent data, and operational visibility.

Why Does Open Innovation Matter?

Flash is built around a simple belief:

An AI assistant that can operate your computer should not require you to hand over every part of your digital life to a closed API.

Open innovation matters here for three main reasons.

1. Local control over private desktop tasks

A desktop assistant may interact with documents, notes, spreadsheets, and application windows containing sensitive information.

Running Gemma locally through Ollama allows supported language-model inference to take place on the user's machine. Those prompts do not need to be sent to a hosted LLM provider.

That gives users more control over where their desktop context is processed.

However, local inference alone does not make the entire application offline or guarantee that every component is private. Flash's cloud coordination, Browserbase sessions, ElevenLabs integration, and remote storage can involve external services. Keeping those boundaries explicit is part of designing a trustworthy system.

2. Less dependence on per-token pricing

A local model can interpret supported tasks without incurring a hosted LLM API charge for every request.

For an assistant that might be invoked throughout the day, that can make a meaningful difference.

Local inference is not literally free: the computer consumes electricity, hardware has costs, and external services may have their own pricing. But it gives users an alternative to making every interaction dependent on paid model inference.

3. Freedom to experiment and improve

Open-weight models give developers more control over how inference is deployed and integrated.

With Gemma and Ollama, I can experiment with prompts, change the command-routing logic, adjust structured-output handling, and test local inference without redesigning the whole application around a proprietary model API.

I can also separate the model from deterministic execution logic, making it easier to test and replace individual components.

That is what open innovation makes possible: not just using AI, but understanding how it fits into a system and having the freedom to change that system.

The Lazy Payoff

Let's revisit Judy's challenge.

Nick thinks productivity means doing everything himself, moving quickly, and making sure everyone notices.

Judy knows better. The real advantage comes from identifying repetitive work, choosing the right tools, and checking the results.

Task	The manual way	The Flash way
Grocery checklist	Unlock phone, open notes, type every item	Dictate supported items and organize the checklist
Expense spreadsheet	Open Excel, create headers, format rows	Request a spreadsheet and let the local agent generate it
Meeting notes	Open an editor and type everything manually	Dictate notes into a supported local workflow
Web research	Switch between tabs and repeatedly inspect pages	Use a browser automation workflow to interact with and extract information
Desktop chores	Repeatedly open applications and perform routine steps	Delegate supported actions to the local agent

The precise time saved depends on the task, hardware, network conditions, and how much review is needed. The goal is to eliminate repetitive manual steps, not pretend every task can be completed instantly.

And Judy never blindly trusts the output. She checks the spreadsheet, verifies the research, and keeps control over important decisions.

That is the difference between useful automation and letting an AI loose on your computer and hoping for the best.

Flash does the repetitive work. Judy makes the decisions. Nick gets humbled.

Honestly, that sounds like a pretty good productivity strategy.

Prize Categories

I'm submitting Flash for the following categories, where the corresponding integrations and implementation meet the challenge requirements.

🏆 Overall Challenge: Slow and Steady

Flash embodies the theme by using open-weight AI and desktop automation to reduce repetitive work and let people reclaim their time.

🌟 Featured Categories

Best Use of Gemma — $200

Gemma 2:2B runs locally through Ollama and supports natural-language intent interpretation and structured parameter extraction in Flash's command pipeline.

Best Use of Render — $200

Render hosts the public web companion and cloud coordination service, connecting the web experience to the separately running local agent.

🤝 Partner Categories

Best Use of ElevenLabs — $100

ElevenLabs provides neural voice output, with a Windows SAPI fallback for supported local speech workflows.

Best Use of Browserbase — $100

Browserbase and Stagehand power cloud browser automation for supported research and data-extraction workflows.

Best Use of MongoDB Atlas — $100

MongoDB Atlas provides persistent storage for supported routines, checklists, and preferences, alongside local fallback storage.

Best Use of Sentry Agent Tracing — $100

Sentry integration supports operational visibility and troubleshooting for agent errors and execution behavior.

What's Next for Flash?

Flash is a starting point for exploring how local-first AI can make desktop automation more approachable.

Some directions I'd like to explore further include:

More robust task planning and execution reporting.
Clearer approval boundaries for sensitive desktop actions.
Better recovery when an application or browser workflow fails.
More detailed performance measurements for local inference and command execution.
Expanded offline workflows that reduce dependence on cloud services.
More reproducible tests for command parsing, file generation, and UI automation.

The aim is not to build an AI that does absolutely everything. It is to build one that does the boring things reliably, explains what it did, and leaves the user in control.

Final Verdict: The Fox Lost. The Rabbit Won. The Sloth Went Back to Work.

Nick Wilde: “Okay, I'll admit it. That sloth is surprisingly useful.”

Judy Hopps: “And what have we learned today, Nick?”

Nick: “Never challenge a rabbit who knows how to automate?”

Judy: “Close enough.”

Flash: (slowly closing the completed report) “Can... I... go... home... now?”

Judy: “Case closed.”

Nick: “This is the worst day of my life.”

Flash: “Sounds... exhausting.”

🦥💤

Built with open-weight AI, Python, Ollama, Gemma 2:2B, Windows automation, React, Render, Stagehand, Browserbase, and a healthy respect for doing less repetitive work.

GitHub: SK-Sathyavada-008/flash

Live Demo: flash-cloud-coordinator.onrender.com

“Change starts with you.” — Officer Judy Hopps

“Yeah, but tomorrow.” — Flash Slothmore 🦥

Team
@veerrr

Rivo: I Built an AI Fee Manager for My Kuchipudi Teacher | Hacktoberfest Week 2

Keerthana Sathyavada — Wed, 14 Oct 2026 18:39:47 +0000

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

The Story Behind Rivo: My Mam, Her Students, and a Birthday Gift

I'm an engineering student, and Kuchipudi is a big part of my life.

My dance teacher, teaches over 60 students. Like many independent dance teachers across India, she manages her academy while teaching classes, coordinating batches, communicating with parents, and keeping track of monthly fees.

And that's where I noticed a problem.

Every month, parents pay their children's dance fees through UPI apps such as Google Pay, PhonePe, and Paytm. Then they send payment screenshots and messages into the respective WhatsApp groups.

Sounds simple, right?

Except there are 60–70 students, multiple batches, different payment dates, missed months, and parents who sometimes pay for two siblings in a single transaction.

Imagine receiving a ₹3,000 payment for two siblings whose monthly fees are ₹1,500 each. The money might have arrived in one transaction, but the teacher still needs to account for two separate students and their respective fee obligations.

Now multiply that across dozens of students.

Someone has to open the screenshots, identify the student, understand which month the payment belongs to, check the amount, update the records, and remember who still owes money.

And a screenshot isn't proof that the money actually reached the bank account.

I kept thinking about how much time and energy this repetitive work could take away from teaching and dancing.

I wanted to build something that would make Mam's life easier. In fact, I initially imagined building it as a birthday gift for her.

Not another app that asks teachers to change their entire workflow. Not another complicated accounting dashboard that requires hours of manual data entry.

I wanted to build something that could do the routine work for her.

That idea became Rivo.

What I Built

Rivo is an AI-powered fee reconciliation and financial bookkeeping platform for independent dance teachers, music academies, tuition centres, and other small educational businesses.

Its goal is simple: turn messy payment evidence into organised fee records while keeping the teacher in control of the money.

Instead of manually reading every WhatsApp message and maintaining a notebook, a teacher can use Rivo to organise payment claims, identify students, reconcile transactions against bank statements, allocate fees, and see who still has outstanding dues.

The product is designed around a crucial distinction:

An AI model can extract payment details. It cannot declare that money has reached the bank.

Rivo separates the process into three stages:

Claimed payment: A parent sends a screenshot or message claiming to have paid.
Matched payment: The claimed transaction reference and amount match a transaction in an official bank statement.
Verified payment: The matched bank transaction is confirmed and allocated to the relevant student's fee obligation.

This distinction is especially important for financial software. An old screenshot, a forwarded receipt, or an AI-generated extraction should never be enough to mark a student's fees as paid.

Who would pay for it?

Rivo is designed for small academies that cannot justify expensive enterprise accounting software but still need reliable financial records.

My initial pricing hypothesis is ₹499–₹999 per month, depending on the features and academy size.

For a teacher managing dozens of students, the value isn't simply a prettier spreadsheet. It's fewer hours spent on repetitive bookkeeping, fewer missed fee obligations, easier sibling allocations, and better visibility into actual collections.

The long-term goal is to make the teacher's involvement minimal: routine reconciliation should be automated, with manual attention reserved for ambiguous or exceptional cases.

Demo

🌐 Live application: https://rivo-app-ss62.onrender.com/
💻 Source code: https://github.com/SK-Sathyavada-008/rivo

Try the interactive demo

The application includes a Phone Simulator that demonstrates a realistic WhatsApp-style workflow with simulated dance academy batch groups.

Click the Phone Simulator button in the navbar to explore the simulated parent messages and payment receipts.

You can also try the demo login:

Email: teacher@naatyavedam.com
Password: naatyavedam123

The simulator demonstrates the intended ingestion and extraction workflow; it does not connect to or read anyone's actual WhatsApp account.

How I Built It

Rivo is built as a TypeScript monorepo with a React frontend, an Express backend, MongoDB Atlas, and an open-weight AI model.

1. Open-weight AI with Google's Gemma

At the heart of Rivo is Google's Gemma 2 9B Instruct (gemma-2-9b-it), accessed through Groq's inference service.

Payment messages are rarely clean or consistent. A parent might write:

"Paid 3000 for Keerthana and Roopa October fee 🙏"
"Sent Rs 1500 for Alekhya UTR 428901248910"
"Fee paid for both children."

These messages contain useful information, but they aren't structured financial records.

Gemma helps transform unstructured payment messages into structured fields that the application can validate:

student_names
claimed_amount
claimed_transaction_reference
confidence
is_untrusted_candidate

For example, a message mentioning two students and ₹3,000 can be converted into a candidate record containing both names and the claimed amount.

However, the model's output remains untrusted. It does not directly update a student's verified payment status.

What happens when the AI endpoint fails?

A small academy shouldn't lose its workflow just because an external inference endpoint is temporarily unavailable.

Rivo includes a deterministic fallback extractor, extractFieldsWithRules, which recognises common Indian currency formats such as ₹, Rs. and /-, along with 12-digit UPI transaction references.

This fallback handles basic extraction without depending on the AI endpoint. Complex or ambiguous messages can still require further review.

The combination of open-weight AI and deterministic validation makes the system more resilient than an implementation that depends entirely on a single model response.

2. The sibling fee-splitting problem

This is one of the most important business rules in Rivo.

Suppose two siblings, Keerthana and Roopa, each owe ₹1,500 for October. Their parent sends a single ₹3,000 payment.

The bank statement contains one transaction, but the academy needs two separate fee allocations.

Rivo's allocation engine uses the relevant student, family, and fee-obligation records to distribute the matched transaction across the appropriate outstanding obligations.

The result is one bank transaction linked to two distinct allocations:

Keerthana: ₹1,500
Roopa: ₹1,500

The system must also account for situations such as outstanding fees from previous months, payments covering multiple months, and amounts that do not match the expected obligations.

These cases require explicit business rules rather than asking an AI model to make financial decisions on its own.

3. MongoDB Atlas and financial data integrity

Rivo uses MongoDB Atlas with Mongoose to manage the application's financial records.

The backend includes models for:

Student
FeeObligation
PaymentEvidence
PaymentTransaction
PaymentAllocation
AuditEvent

Every tenant-owned database operation is scoped to the authenticated teacher, helping prevent one academy from accessing another academy's records.

The reconciliation workflow also includes transaction deduplication, unique-index protections for transaction references, and audit logging.

This matters because uploading the same bank statement twice should not create duplicate collections or inflate the academy's revenue.

A financial ledger needs more than an AI model that usually gets the answer right. It needs predictable behaviour when the same evidence arrives twice, the data is incomplete, or something goes wrong.

4. React, Express, and Render

The frontend uses React 19, Vite, Tailwind CSS, Lucide icons, and Recharts for financial dashboards.

The backend uses Express and serves the compiled frontend from the same deployed web service.

Rivo is hosted on Render as a unified application, with the Express API and React single-page application served through one service.

This simplifies deployment and avoids many cross-origin cookie issues associated with maintaining separate frontend and backend origins.

5. Observability with Sentry

Financial reconciliation failures should not disappear silently.

Rivo includes Sentry integration for monitoring application exceptions and troubleshooting failures in the reconciliation workflow.

The objective is to make it easier to identify problems such as malformed bank CSV files, failed AI extraction requests, and unexpected reconciliation errors.

Production monitoring must also be configured carefully so that sensitive payment information and student data are not unnecessarily captured in telemetry.

Why Open Innovation Matters

The Hacktoberfest Week 2 prompt asks an important question: what does open innovation make possible that a closed approach might not?

For Rivo, the answer comes down to cost, adaptability, and control.

1. Making the economics work for small businesses

An independent dance teacher may collect modest monthly fees from dozens of students. A costly AI workflow can quickly make the product commercially impractical.

Gemma gives Rivo an open-weight model that can be evaluated, adapted, and served through different compatible inference setups.

Using an inference provider such as Groq makes experimentation accessible without requiring me to maintain dedicated GPU infrastructure.

The goal is to keep the AI component affordable enough that the subscription price makes sense for the teacher.

2. Building for a specialised problem

A generic chatbot can extract an amount from a sentence. Rivo needs to understand the relationship between a student, a family, a fee obligation, a claimed payment, and an actual bank transaction.

The model handles language interpretation, while deterministic application logic enforces the academy's financial rules.

Because Gemma's weights are available, the model can also be evaluated against real-world message patterns and potentially adapted for the language and payment conventions used by Indian educators.

The model is replaceable; the financial rules remain explicit and testable.

3. Privacy is an architectural responsibility

Payment evidence can contain names, transaction references, phone numbers, and other sensitive information.

Open-weight AI creates more flexibility over where and how inference runs, including the possibility of moving inference to a controlled or local environment.

However, using an open-weight model through a hosted provider does not automatically make the application private. That depends on the provider's data policies, configuration, and the application's handling of sensitive information.

Rivo's architecture aims to minimise unnecessary exposure, isolate each teacher's records, and keep payment verification separate from model predictions.

4. Graceful failure instead of total dependence

If an external model endpoint becomes unavailable, the deterministic extraction fallback can still handle supported currency patterns and transaction references.

This does not mean the entire application works offline. It means that a basic part of the extraction pipeline does not have to stop simply because the AI service is unavailable.

For a small business, that distinction matters.

Open innovation isn't just about using a model whose weights are available. It's about retaining the freedom to inspect, adapt, replace, and improve the technology as the product grows.

The Person I Want to Build This For

My Mam is the reason this project exists.

As a Kuchipudi student, I get to see the teaching side of a dance academy, but building Rivo made me think about everything that happens outside the classroom.

The preparation, the coordination, the parent messages, the fee tracking, and the administrative work all take time away from what a dance teacher actually wants to do: teach, practise, and help students grow.

I originally imagined this project as a birthday gift for Mam. I wanted to use what I was learning as an engineering student to solve a problem in a world I already knew and cared about.

That personal connection shaped the product's priorities.

I don't want Mam to learn complicated accounting software. I don't want her to abandon the UPI apps parents already use. And I don't want her to spend every month manually entering information that a system should be able to organise for her.

I want her to open Rivo and understand the state of her academy's fees without spending hours piecing together WhatsApp messages.

The real success of Rivo would be measured not by how much AI it uses, but by how much repetitive work it removes from a teacher's life.

My First User: From Personal Problem to Potential Customer

My first intended user is my own dance teacher.

She represents exactly the kind of person I want Rivo to serve: an independent educator who manages a growing student base without a dedicated accounting team.

The problem is concrete, the workflow is familiar, and the potential value is measurable in time saved and fewer reconciliation mistakes.

My initial pricing hypothesis is ₹499 per month, with the possibility of higher tiers for larger academies.

The next milestone is to put the application in Mam's hands, observe how it fits her actual monthly fee workflow, and measure whether it reduces her manual work without introducing new complexity.

One feature I particularly want to explore is one-click fee receipt generation, so a teacher can respond to parents with a clear payment status without repeatedly composing individual messages.

I am not claiming that Mam has already adopted or paid for Rivo. Her day-to-day workflow inspired the project, and validating it with her is the next important step.

If Rivo can save her hours every month, I will have achieved something more meaningful than building another portfolio project.

What's Next?

The current application establishes the core workflow, but there is more to do before Rivo can become a dependable tool for real academies.

My priorities are:

Real-world validation: Test the workflow with Mam and identify where it fails to match actual academy operations.
Less manual work: Reduce the teacher's involvement in routine processing while preserving control over ambiguous cases.
Better reconciliation: Handle multiple-month payments, partial payments, sibling allocations, duplicate uploads, and unmatched transactions reliably.
Clearer parent communication: Explore generating payment receipts and outstanding-fee reminders.
Privacy and reliability: Strengthen data protection, auditability, and monitoring before expanding to more academies.

I want to grow Rivo based on what teachers actually need, rather than adding AI features simply because they sound impressive.

Prize Categories

Rivo is being submitted for the following partner categories, based on the technologies used in the project:

🏆 Best Use of Render — $200: Hosting the full-stack application as a unified web service.
🏆 Best Use of Gemma — $200: Using Google's open-weight Gemma model for structured extraction from unstructured payment messages.
🏆 Best Use of MongoDB Atlas — $100: Storing tenant-scoped student, fee, transaction, allocation, and audit records.
🏆 Best Use of Sentry Agent Tracing — $100: Monitoring application and reconciliation errors, with further scope to demonstrate detailed traces and agent execution.

Final Thoughts

Rivo started with a problem I could see in the life of someone who matters to me.

It has become an opportunity to combine engineering, open-weight AI, financial integrity, and a small-business use case that I genuinely care about.

There is something exciting about being able to take a frustrating monthly routine and ask, "Could I build something that makes this easier?"

That is what I want open-source AI to enable: not just bigger models or more impressive demos, but useful tools that solve specific problems for real people.

And if this little project eventually gives my Mam more time to teach Kuchipudi instead of tracking payment screenshots, it will have accomplished exactly what I hoped for when I started building it.

Built with ❤️ for my Mam, Indian dance gurus, independent educators, and the Hacktoberfest 2026 Open-Source AI Challenge.

Try Rivo | Explore the source code on GitHub

Team
@veerrr

TouchGrass 🌿 — An AI Companion That Tells You to Put Your Phone Away

Keerthana Sathyavada — Wed, 07 Oct 2026 04:11:47 +0000

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

🌱 What I Built

We spend a ridiculous amount of time staring at screens — and then we build AI apps that ask us to stare at them even more.

So I decided to build something with the opposite goal.

TouchGrass is an AI-powered outdoor companion that gives you a reason to step away from your screen and actually go outside.

The idea is simple:

Ask AI → Get a small outdoor challenge → Put your phone away → Go touch some grass. 🌿

Instead of giving you another endless chat conversation, TouchGrass gives you a quick, playful real-world activity that you can actually do.

Maybe it's finding something unusual around you, paying attention to sounds you've been ignoring, observing your surroundings differently, or simply taking a few minutes to explore.

The AI gives you the nudge.

The rest happens outside the screen.

✨ What Can You Do With TouchGrass?

🌱 Quick Outdoor Quests

Don't have much time?

Tell TouchGrass how much time you have and get a small outdoor activity that you can complete during your break.

No complicated planning. No giant itinerary.

Just:

Get a quest → Put your phone away → Go.

🗺️ Explore Your Surroundings

TouchGrass turns going outside into a small adventure.

Instead of walking around while scrolling through your phone, the app encourages you to actually notice what's around you.

📸 What Did I Just See?

Found something interesting outside?

Take a picture and use AI to help identify what you're looking at and turn the discovery into another little outdoor activity.

Because apparently even touching grass needed AI. 😂

📱 Built for the Real World

TouchGrass is designed as a mobile-first Progressive Web App, so it feels much more like a small outdoor companion than a traditional website.

The goal isn't to keep you inside the app.

The goal is to get you out of it.

🎮 Try It

🌐 Live App

https://sk-sathyavada-008.github.io/touch-grass/

Open it on your phone and try it during your next break.

You can also add it to your home screen and use it like an app.

⚙️ Backend

https://touch-grass-trdy.onrender.com/

The backend API is deployed on Render and handles the application's server-side functionality and AI requests.

💻 Open Source

The complete project is available on GitHub:

https://github.com/SK-Sathyavada-008/touch-grass

Feel free to explore the code, try it locally, or contribute.

🛠️ How I Built It

TouchGrass combines an AI backend with a mobile-first web experience.

🤖 Gemma

Gemma is used as the AI layer behind the outdoor experiences.

Instead of using AI to generate another long conversation, I wanted to use it for something much smaller and more useful:

turning a little bit of free time into a reason to go outside.

The prompts are designed around short, actionable outdoor activities rather than generic chatbot responses.

🎨 Frontend

The frontend is built as a mobile-first PWA with:

Vite
TypeScript
Responsive UI
PWA capabilities
A playful tactile/clay-inspired visual style
Small animations and interactive elements

I wanted the interface to feel friendly and playful rather than like another productivity dashboard.

⚙️ Backend

The backend is built with:

Node.js
Express
AI API integration
Request validation
CORS handling
Environment-based configuration

It is deployed on Render.

🍃 MongoDB

MongoDB is used for storing application data such as outdoor experiences and user activity data.

The flexible document structure also makes it easier to extend the app with more types of adventures and discoveries in the future.

🚀 GitHub

GitHub is used for source control and deployment of the frontend.

The project is completely open source, so the entire development process — from the code to the deployment — is available to explore.

💡 Why Build Something Like This?

AI is becoming incredibly good at helping us do things faster.

But sometimes faster isn't the thing we need.

Sometimes we need to stop.

Look around.

Walk outside.

Notice that weird-looking tree.

Hear the birds.

Feel the sunlight.

Talk to a friend.

Touch some grass.

TouchGrass is my small experiment in using AI to reduce screen time instead of increasing it.

And honestly, I think AI telling you:

"Okay, enough screen. Go outside."

is probably one of the healthiest things an AI can say. 🌿

🏆 Challenge Categories

TouchGrass was built using technologies aligned with several Hacktoberfest challenge categories, including:

Gemma — powering the AI-generated outdoor experiences
Render — hosting the backend API
MongoDB Atlas — storing application data
GitHub — open-source development and deployment

🌎 What's Next?

There are plenty of directions I'd love to take this project:

Better location-aware outdoor quests
More personalized adventures
Richer outdoor discovery/identification
Offline capabilities
Adventure history and journals
More accessibility options
Community-created outdoor challenges

But the core idea will stay the same:

Technology should sometimes help us put technology down.

🌿 Now Go Touch Some Grass

If you try the app, I'd genuinely love to know what kind of outdoor quest it gives you.

And if you spend 45 minutes talking to the AI instead of going outside...

you completely missed the point. 😂

Try TouchGrass:
🌐 https://sk-sathyavada-008.github.io/touch-grass/

Source Code:
💻 https://github.com/SK-Sathyavada-008/touch-grass/

Backend:
⚙️ https://touch-grass-trdy.onrender.com/

Thanks for reading — now close this tab and go outside. 🌱

Team
@veerrr

Nudge Veer — I Built My Friend a Personal AI Coding Companion (With real treats)

Keerthana Sathyavada — Fri, 02 Oct 2026 14:12:05 +0000

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

What I Built

Meet Nudge Veer.

It's an AI coding companion I built specifically for my best buddy.

Veer and I spend a lot of time solving DSA and LeetCode problems. Sometimes the problem is the problem. Sometimes the problem is Java. And sometimes... the problem is simply staring at the screen for 20 minutes and refusing to move.

I didn't want to build him another productivity dashboard.

I wanted to build something that could nudge him when he's stuck, plan things when he doesn't know where to start, roast him when he's trying to cheese the system, and actually reward him when he earns it.

So that's what Nudge Veer became.

THINK

Veer can bring a coding problem into THINK mode and interact with Gemma while solving it.

The AI receives context such as his coding state, mood, problem, language, hint history and current hint level.

Instead of immediately dumping a solution, Gemma decides what kind of intervention makes sense:

ask a question
give a conceptual nudge
provide a hint
help with syntax
adjust the difficulty
or occasionally tell him that yes, he is in fact cooked 😭

The philosophy is simple:

Nudge, don't replace.

🗺️ GAME PLAN

Sometimes the problem isn't solving a problem.

It's not knowing what to learn next.

Veer can enter something like:

"I want to learn Dynamic Programming."

Instead of giving him a giant generic checklist, Gemma first asks for relevant context — experience, timeframe, available time, goals, etc.

It then generates a structured, multi-phase roadmap with:

phases
topics
tasks
milestones
timelines
practice recommendations
LeetCode problems

The goal is to turn:

"I should probably learn this."

into:

"Okay. I know what I'm doing today."

😈 CHALLENGE

This is where I decided to make things slightly evil.

Challenges have difficulty levels and points, but points aren't handed out for clicking buttons.

There is an anti-cheese system:

opening a challenge → no points
repeating a challenge → no farming
using hints → reduced reward
asking for the full solution → zero challenge points

Because otherwise Veer would discover the optimal strategy in approximately 14 seconds.

🏆 BADGES

Badges are earned through actual milestones rather than simply opening pages.

Some are intentionally ridiculous.

🍦 TREATS

This is my favourite part.

The points aren't just imaginary internet numbers.

They can be exchanged for actual treats from me (SK).

Current rewards include:

🍦 Ice Cream
🌯 Veg Frankie
🖊️ Pen

And then there's the ridiculous one:

💀 THE 1000-COIN MISTAKE

If Veer somehow saves up 1000 coins (hopefully he doesn't 🤐), he unlocks a much bigger real-world treat.

The coins are persisted through MongoDB, and when a treat is redeemed, the balance actually decreases.

So yes, there is now a database keeping track of whether I owe my friend food.

🎮 The Home Page

I didn't want the home page to look like a SaaS dashboard.

It's basically a small interactive title screen.

The centerpiece is a 3D Nudge Veer logo with:

#From Developer to the Best PM

The logo reacts to the user's mouse with 3D perspective, lighting and depth effects.

There is also a small weird playable character that you can poke because apparently that was necessary.

The page also contains:

😈 the Evil Scorekeeper
💌 personal messages I've written for Veer
🪙 his earned coins
🎁 his real-world treats

And, of course, some subtle Mr. Bean and Motu Patlu doodles in the background.

It is intentionally more like a game title screen made for one friend than a traditional productivity app.

🚀 Demo

Live: sk-sathyavada-008.github.io/nudge/

The project is available on GitHub with the complete source code and setup instructions; Render deployment was attempted but is currently unavailable.

The local development setup uses Gemma through Ollama, while the deployed environment uses the configured fallback AI provider where required.

MongoDB Atlas persists the application's reward and progress data across sessions.

💻 Code

https://github.com/SK-Sathyavada-008/nudge

🛠️ How I Built It

The stack is:

Gemma 2 — the open-weight AI model powering the coding companion and roadmap generation
Ollama — local model runtime during development
React 19 + Vite — frontend
Three.js / React Three Fiber — interactive 3D home page
Node.js + Express 5 + TypeScript — backend
MongoDB Atlas — persistent application data
Antigravity IDE — AI-assisted development

There are two major AI workflows.

THINK Agent

The THINK workflow provides Gemma with structured context such as:

mood
coding state
hint level
hints used
problem
programming language

Gemma then determines the appropriate next interaction instead of simply returning a generic answer.

GAME PLAN Agent

The roadmap workflow works differently.

It first gathers the information necessary to understand the user's goal and constraints, then generates a structured roadmap that the frontend can render and track.

The important part for me was making AI an actual decision-making component of the product, rather than putting a chatbot in the corner and calling the project AI-powered.

🌱 Why Open Innovation Matters

Building this around an open-weight model changes what I can do with the product.

1. I can run the model locally

With Gemma and Ollama, I can experiment with the AI companion locally without requiring every interaction to go through a hosted API.

That matters for a personal tool where experimentation is part of the fun.

2. I control the AI behaviour

Nudge Veer isn't supposed to sound like a generic assistant.

It's supposed to sound like something that understands the context of the application — including when a hint should be given, when the user should be pushed to think, and when a little teasing is appropriate.

Using an open model gives me much more control over that behaviour and the surrounding system.

3. The system is replaceable

The application keeps the model interaction behind the backend rather than tightly coupling the UI to one model provider.

That means experimenting with different models and runtimes doesn't require rebuilding the entire application.

4. It makes personal AI more accessible

This project started with a very small problem:

"My friend gets stuck while learning."

It didn't require a huge AI platform.

It required an open model, a small application, some creativity, and knowing the person you're building for.

That's what I like most about open innovation.

🤖 My Agent Session

I built Nudge Veer using Antigravity IDE with an AI-assisted development workflow.

The agent helped with things including:

React + Express architecture
MongoDB persistence
the Gemma integration
structured roadmap generation
challenge/reward logic
the interactive 3D home page
responsive UI
debugging deployment issues

One particularly fun debugging session involved an Express 5 routing change where a wildcard route caused a TypeError, requiring the backend routing approach to be changed.

The project also went through several iterations where I deliberately removed features that made it feel too much like a productivity tracker.

No confidence score.

No streak counter.

Instead:

AI companion + challenges + chaos + actual food.

🏆 Prize Categories

I'm submitting Nudge Veer for:

Best Use of Gemma

Gemma is central to both major AI workflows:

THINK — contextual coding assistance
GAME PLAN — personalized roadmap generation

Best Use of MongoDB Atlas

MongoDB Atlas provides persistent storage for things like:

user reward balance
challenges
badges
treat redemptions
roadmap/progress data

❤️ Why I Built It

The easiest way to explain Nudge Veer is this:

I didn't start with a business idea.

I started with a friend.

I know the person who is going to use this. I know the problems that annoy him. I know the jokes he'll understand. I know what kind of motivation he'll ignore.

So instead of asking:

"What AI product should I build?"

I asked:

"What would actually make my friend's day a little better?"

And somehow that turned into an AI coding companion that keeps track of whether I owe him an ice cream.

That's Nudge Veer.

Your brain isn't broken. It just needs a nudge.

Dashboards aside, Veer loved the “Messages From SK” section. Because what's friendship without a roast? 😂

#BestBuddyEver

Team
@veerrr