DEV Community: Kushagra Bhardwaj

ScopeGuard Local: A Local-First AI Assistant for Freelancers Fighting Scope Creep

Kushagra Bhardwaj — Sun, 18 Oct 2026 17:36:09 +0000

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

What I Built

ScopeGuard Local is an open-source, local-first AI tool that helps freelancers identify potential scope creep before a small client request turns into a much larger project.

Freelancers often hear requests like “Could you also add a customer dashboard?” or “Can we include subscription payments?” after a project has already been agreed upon. These requests can introduce additional work, time, and costs, but figuring out whether they fit the original agreement isn't always straightforward.

ScopeGuard Local helps freelance developers, designers, and small digital agencies compare new client requests against their project agreements.

Here's how it works:

Upload an agreement: Provide a UTF-8 text file or a PDF with selectable text.
Analyze a client request: The local AI compares the new request with the agreement.
Review the evidence: Get an explanation and supporting quotations from the original document.
Understand the result: Requests are classified as in_scope, potential_scope_change, or needs_review.
Draft a change order: Generate an editable proposal, with optional AI-assisted cost and timeline estimates.
Export the proposal: Copy it or download it as Markdown or PDF.

The important part is that ScopeGuard doesn't just return an AI-generated verdict. It checks whether its evidence quotations actually appear in the submitted agreement and flags missing or invalid evidence for human review.

Who would pay for this? Freelancers, independent developers, designers, and small agencies who want to spend less time handling scope disputes and preparing change requests. The project is currently an open-source MVP, not a paid product.

Demo

ScopeGuard Local currently runs on your own machine, with a React frontend, FastAPI backend, and local inference through Ollama.

To try it, follow the setup instructions in the repository README. You'll need Python, Node.js, Ollama, and the Gemma 3 4B model.

The repository includes synthetic sample agreements and requests that you can use to explore the workflow without uploading real client contracts.

A hosted demo or video walkthrough is not currently linked here.

scopeguard.mp4 - Google Drive

drive.google.com

Code

GitHub repository:

Kush05Bhardwaj / ScopeGuard

A local-first assistant for comparing client requests with an agreed project scope.

ScopeGuard

ScopeGuard helps freelancers compare a new client request with a project agreement, review the supporting passages, and prepare an editable change-order proposal. The current workflow uses a local FastAPI service and Ollama by default.

What works today

Upload UTF-8 .txt agreements or text-based .pdf agreements. PDF text keeps page references. Uploads are parsed in memory; scanned PDFs are not OCR processed.
Compare a client request with the agreement using Ollama and Gemma 3 4B.
Review one of three classifications: in_scope potential_scope_change, or needs_review.
Check the model's evidence quotations against the original agreement text Missing or invented evidence requires human review. Exact quotations do not prove that the model interpreted them correctly.
Generate a change-order proposal from the validated analysis, edit it in the browser, then copy it or download it as Markdown or PDF. The local model can suggest rough costs and timelines for missing values…

View on GitHub

ScopeGuard Local is open source under the MIT License.

The repository includes the frontend, backend APIs, analysis and reporting services, automated backend tests, documentation, and synthetic sample data.

Contributions, bug reports, and feedback are welcome!

How I Built It

The application combines a web interface, a Python API, and an open-weight language model running locally.

Technology stack:-

Frontend: React, Vite, and TypeScript
Backend: Python and FastAPI
Local AI inference: Ollama with Gemma 3 4B
Document processing: PyMuPDF for extracting text and page references from PDFs
Validation: Pydantic for structured request and response validation
Exports: Editable Markdown proposals and PDF downloads

The core workflow follows five steps:-

Extract text from the uploaded agreement.
Send the agreement text and client's new request to the local model.
Validate the model's structured response and check its evidence quotations against the source text.
Generate a change-order draft based on the validated analysis.
Let the freelancer review, edit, and export the result.

The model is treated as an untrusted component. If its output is malformed, evidence is missing, or the request is ambiguous, the application can require further review rather than presenting an unsupported conclusion as fact.

ScopeGuard can also ask the local model for rough cost and timeline suggestions when those details are missing. These suggestions and their assumptions need to be reviewed by the freelancer before sharing a proposal.

The current version does not include OCR for scanned PDFs, persistent project history, authentication, or automatic client communication. It is deliberately focused on the core workflow.

Why Does Open Innovation Matter?

Open innovation matters here because a tool dealing with client agreements should give users control over how their documents are processed.

By building around open-source components and a locally run open-weight model, ScopeGuard Local can operate without requiring a proprietary hosted AI API for its default inference workflow.

That makes a few things possible:-

More control over documents: Agreement text can remain on the user's machine when the application is configured to use local services.
Lower dependence on a hosted AI provider: Users can run their own inference setup and configure a compatible Ollama model.
Inspectable implementation: Developers can examine how prompts, evidence validation, API routes, and proposal generation work.
Room for community contributions: Others can improve document parsing, model validation, accessibility, testing, and supported workflows.

Local-first operation is not an automatic privacy guarantee. Configuring services to use a remote host may send document contents to that host, and model-generated analysis can still be incorrect. Users should review results and avoid uploading confidential agreements to services they don't trust.

For this project, open innovation is about more than using an open model. It is about making the workflow, its limitations, and its safeguards inspectable and improvable.

Final Thoughts

Scope creep is a small problem that can become expensive over time. My goal with ScopeGuard Local is to give freelancers a practical starting point for evaluating new requests, finding relevant agreement text, and preparing clearer conversations about additional work.

It's an MVP, and there is still plenty to improve. Feedback on the analysis workflow, evidence validation, usability, and local model support would be especially valuable.

Try the project, explore the code, and let me know what you'd improve next!

RE-ALM — Turn Your Real World Into an RPG Adventure 🌍⚔️

Kushagra Bhardwaj — Sun, 11 Oct 2026 13:30:10 +0000

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

What I Built

What if going outside felt less like another item on your to-do list and more like starting a new anime adventure?
That's the idea behind RE — an AI-powered, real-world RPG designed to turn everyday activities into quests, progress, and rewards.
Instead of spending every gaming session in a virtual world, RE encourages players to explore the one they already live in. A walk, an outdoor activity, or a small personal challenge can become part of a larger adventure.

The core gameplay loop combines three things:

AI-generated quests: An AI Game Master generates structured adventures rather than simply chatting with the player.
EXP and progression: Completing quests contributes to player progression, including experience points, levels, and stats.
Aether and summons: Players earn Aether through the game's reward system and spend it on summons, with rarity tiers ranging from R and SR to SSR and UR.
Inventory and collection: Summoned rewards become part of the player's collection, giving progression a tangible in-game goal.

The idea is to make the phone a launchpad, not the destination. Players should be able to discover their next objective, head outside, complete it, and return to see their progress.

RE is being developed as a phased project, with the current implementation focused on the core gameplay loop: player setup, AI quest generation, quest tracking, progression, the Aether economy, summons, and inventory.

Demo

Live demo / video walkthrough: [https://drive.google.com/file/d/1IZKfCaZ2hCK589dGUSmEYdJ7sf-gPa3j/view?usp=sharing]
The demo should show the complete loop:

Open and view the player HUD.
Generate an adventure with the AI Game Master.
Start and complete a quest using the currently implemented verification flow.
Claim the resulting progression rewards.
Use Aether to perform a summon and view the result in the collection. I want the demo to show not just the interface, but how the system connects AI-generated content to actual gameplay progression.

Code

GitHub repository: https://github.com/Kush05Bhardwaj/Re-Alm
The project uses a monorepo structure with a Next.js frontend and a Python FastAPI backend. The backend handles gameplay APIs, AI quest generation, progression, the Aether ledger, summons, and inventory, with MongoDB used for persistence.

How I Built It

The main technology choices are:

Next.js, TypeScript, and Tailwind CSS for the web interface.
Python and FastAPI for the backend APIs and gameplay logic.
Gemma through Ollama for open-weight AI inference and AI-generated quests.
MongoDB for player data, quests, progression, economy transactions, and collection state.

The important architectural decision was to treat the AI as a game-content generator, not just a chatbot.

The AI Game Master is intended to produce structured quest data that the backend can validate and use in the gameplay system. That data connects to quest tracking, EXP and level progression, Aether rewards, and the summon and inventory systems.

This separation matters: the model proposes the adventure, while application logic manages the player's state and rewards.

The project has been implemented in phases so that the basic gameplay loop can be established before expanding into more advanced systems such as adaptive adventures, NPCs, classes, bosses, and persistent world events.

Why Does Open Innovation Matter?

For RE, open innovation matters because the AI Game Master is one of the core systems of the game.
Using an open-weight model such as Gemma gives the project more flexibility than building the entire experience around a proprietary, hosted model API.

First, local inference is an option. With Gemma running through Ollama, the model can be run locally on a suitably configured machine. That creates a path toward experimenting with AI-generated adventures without sending every prompt to a third-party inference service.
Second, the model is not a permanent dependency. An open model-based architecture makes it easier to experiment with different models, compare their quest-generation quality, and adjust prompts and output validation as the game evolves.
Third, experimentation becomes more accessible. An AI Game Master needs to generate useful, structured content consistently. Being able to experiment locally can make development more practical and avoid relying entirely on per-request hosted inference costs.

Open innovation also comes with real engineering responsibilities. A generated quest must be validated before it affects gameplay, and local inference does not automatically make every part of the application offline or private. RE still needs careful handling of quest safety, reward integrity, and player data.

For me, the goal is to make AI-powered gameplay more customizable and approachable while keeping the actual game rules under the application's control.

What's Next for RE:ALM?

The current implementation covers the foundational gameplay loop through Phase 8, including AI-generated quests, progression, the Aether economy, summons, and inventory. But this is only the beginning.

Here's what's planned next:

Adaptive Adventures & Discovery** — quests that adapt to player progress, difficulty, and discoveries.
Deeper Immersion** — voice-based, screen-off gameplay, NPC interactions, abilities, and character classes.
World Building** — multiple realms, bosses, exploration, fog of war, and dynamic world events.
Social & Persistent Worlds** — parties, guilds, leaderboards, an improved economy, and AI-driven storylines.
Advanced Immersion** — richer audio experiences, wearables, and future AR/VR exploration.
Reliability & Release** — security, privacy, testing, UI polish, mobile/PWA improvements, analytics, and deployment.
Documentation & Beyond** — complete documentation, challenge submission, a clearly defined MVP, and the long-term roadmap.

RE:ALM is being built incrementally. The goal isn't to add every feature at once, but to create a reliable core experience before expanding the world.

Final Thought

The world already has enough screens competing for our attention. What if technology helped us engage with the world instead?

RE is my attempt to explore that idea through AI, RPG progression, and real-world quests.

Your reality. Your realm. Your adventure.

I Built an AI That Turns My Friend's Voice Notes Into Searchable Memories

Kushagra Bhardwaj — Sun, 04 Oct 2026 17:12:38 +0000

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

What I Built

My friend sends a lot of voice messages.
The problem isn't receiving them. The problem is remembering what was actually said later.
A voice note might contain a task, a person's name, a plan for next week, an important date, or something that needs to be done later.
But once the conversation gets buried under dozens of other messages, finding that information again becomes surprisingly difficult.
So I built Voice → Life.

Voice → Life turns voice messages into structured, searchable memories using open-source tools, an open-weight language model, and local AI inference. Instead of manually listening through old voice notes, you can give Voice → Life a recording and let it:

Voice Note
    ↓
Speech-to-Text
    ↓
AI Understanding
    ↓
Memory Extraction
    ↓
SQLite
    ↓
Timeline / Search / Questions

For example, a voice note like:

"Kal 11 baje Rahul ko internship ke documents bhej dena. Aur Monday ko uska interview hai."

can become memories such as:

Task: Send internship documents
Person: Rahul
Time: 11:00
Event: Interview
Person: Rahul
Date: Monday

And instead of remembering which voice note contained the information, you can ask:

"What did I need to send Rahul?"

and Voice → Life answers using the stored memories.

Why I built it

I wanted to build something that solves an actual everyday problem for a friend, rather than making another generic chatbot.
Voice messages are convenient for communicating.
They're terrible as a database.
Voice → Life is my attempt to bridge that gap.

Demo

Demo Video: Watch the Voice → Life demo

The demo shows the complete flow:

Upload a voice message
Transcribe it
Let the AI understand the transcript
Extract useful memories
Store them
View them on the timeline
Search memories
Ask questions about them

Code

The complete project is open source:
GitHub:

Kush05Bhardwaj / Voice-Life

🎙️ Voice → Life

Turn your voice into useful memories.

Voice → Life is an open-source, local-first AI application that transforms voice notes into structured, searchable memories and actionable information.

Instead of letting important information get buried inside voice recordings, Voice → Life uses open-source AI to understand what was said, extract useful information, and let the user decide what should be remembered.

✨ What It Does

Give Voice → Life a voice note like:

"Bro kal 11 baje Rahul ko internship ke documents bhej dena. Aur usko bol dena ki interview Monday ko hai."

It can turn that into:

🔔 Task
Send internship documents

👤 Person
Rahul

📅 Event
Interview — Monday

The user can review the extracted information and choose what to save.

Later:

"What did I need to send Rahul?"

Voice → Life can retrieve the relevant memory.

🎯 Core Idea

🎙 Voice
   ↓
📝 Transcription

…

View on GitHub

The project is built so that the core AI pipeline can run locally rather than depending on a proprietary AI API.

How I Built It

The stack is intentionally simple.

Architecture:

┌──────────────────────┐
│      Frontend        │
│ Next.js + TypeScript │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│       FastAPI        │
│      Backend         │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│    faster-whisper    │
│   Speech-to-Text     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Ollama + Open Model  │
│   AI Understanding   │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│ Memory Extraction    │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│       SQLite         │
└──────────┬───────────┘
           │
           ▼
    Timeline / Search
        / Q&A

Speech-to-Text

For transcription, I use faster-whisper.
This became particularly interesting when I started testing the project with real voice messages.
Normal benchmark-style English isn't the only thing a personal assistant needs to understand.
Real people mix languages.
My voice-note tests included Hinglish (Hindi + English) and code-switched speech, which exposed weaknesses in the initial lightweight Whisper configuration.
That forced me to treat transcription quality as an actual engineering problem rather than assuming:

audio → text = solved.

Open-Weight AI

The understanding layer uses an open-weight language model through Ollama.
The model receives the transcript and extracts useful information such as:

tasks
events
people
places
plans
facts
reminders The model is explicitly instructed not to invent information that isn't present in the transcript.

Memory Storage

The extracted information is stored in SQLite.
I deliberately didn't start with a complicated vector database or large RAG pipeline.
For the MVP, structured memories are enough.
That also keeps the project easy to run and understand.

Asking Your Memories

The final layer lets users ask natural-language questions about their memories.
For example:

"What did I need to send Rahul?"

The relevant stored memories are passed to the language model, which generates the answer.
The model isn't supposed to make up an answer when the information isn't present.

Why Does Open Innovation Matter?

This project deals with something much more personal than a normal chatbot:
people's voice messages
Voice notes can contain conversations, names, plans, schedules, personal information and things people simply don't want uploaded somewhere else.
That's one of the reasons open-source AI mattered to me while building Voice → Life.
The core AI components can run locally:

faster-whisper handles speech recognition
Ollama provides local model inference
an open-weight LLM handles understanding
SQLite stores the memories locally That changes the relationship between the user and the AI. Instead of:

My private voice
       ↓
Third-party API
       ↓
AI service

the goal is:

My private voice
       ↓
My machine
       ↓
Open AI models
       ↓
My memories

Open models also give developers much more freedom to experiment.
If transcription isn't good enough for Hinglish, I can change the model or configuration.
If the language model isn't performing well, I can replace it.
I'm not locked into one proprietary API or one provider's ecosystem.
For a project built around personal memories, that control matters.

What I Learned

The biggest lesson from this project was that building an AI application isn't just about putting an LLM in the middle of an architecture.
The interesting problems appeared at the boundaries:
Audio → Speech
Is the transcription actually accurate?
Speech → Meaning
Can the model distinguish a task from casual conversation?
Meaning → Memory
What information is actually worth keeping?
Memory → Answer
Can the system answer a question without hallucinating?
And most importantly:
Does the final result solve the original person's problem?
That's what I wanted to explore with Voice → Life.

What's Next?

The current version is intentionally an MVP.
Some ideas for future versions include:

better multilingual and Hinglish support
WhatsApp voice-message integration
task/reminder generation
notifications
stronger semantic search
local-first privacy controls
better confirmation/editing before memories are saved But I intentionally stopped the first version before turning it into a giant AI assistant. The core idea had to work first. Voice in → useful memory out.