ScopeGuard: Helping Freelancers Handle Scope Creep with Open-Weight AI

Juan Esteban Lopez Aranzazu — Wed, 14 Oct 2026 15:06:11 +0000

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

What I Built

Freelancers know the situation: a client asks for one more feature, another revision, or an additional deliverable that was never part of the original agreement.

The problem isn't always deciding whether the request is included. It's finding evidence in the agreed scope and responding professionally without damaging the client relationship.

That's why I built ScopeGuard, a web application that compares new client requests against an agreed project scope and helps freelancers decide how to respond.

Here's what it does:

Define the scope: Record the project's deliverables, features, exclusions, and relevant agreement terms.
Analyze client requests: Break a new request into individual items and compare them against the supplied scope.
Review evidence: Inspect supporting quotes and identify potential additions or ambiguous requirements.
Draft a reply: Generate a professional response to negotiate additional work, ask for clarification, or decline a request.

The key difference from a generic AI email writer is that ScopeGuard attempts to ground its analysis in the original agreement instead of simply producing a plausible-sounding answer.

Who would pay for it? Freelance developers, designers, and small agencies that regularly deal with changing requirements. A possible business model is a free tier with limited analyses and a paid tier for more projects and usage. That's a hypothesis I want to validate with actual users.

Demo

The screenshots below showcase ScopeGuard's main workflow, from defining the agreed project scope to analyzing new client requests, reviewing supporting evidence, and generating a suggested reply.

1. Project Scope

2. Request Analysis

3. Evidence

4. Reply Generator

Code

GitHub repository: https://github.com/JuanLopezAranzazu/scopeguard

The repository contains the application source code and instructions for running it locally.

How I Built It

ScopeGuard is built with:

React, Vite, and TypeScript for the frontend.
Chakra UI for interface components.
FastAPI and Python for the backend.
Ollama for local model inference.
Qwen2.5 3B as the default language model.
Browser localStorage for persisting application data.

The application sends the project scope and the client's request to the backend, where the model analyzes the requested changes. The frontend then presents the results and allows the user to generate a response.

Making a Small Model More Useful

One of the main challenges is that language models can confidently make claims that aren't supported by the supplied agreement.

ScopeGuard combines model output with application-level validation:

The request is evaluated in smaller parts.
Structured output is validated against the expected schema.
Supporting quotes are checked against the original scope text.
A missing or invalid quote prevents the application from treating an unsupported claim as verified evidence.
The final classification is computed in application code rather than blindly accepting the model's verdict.

These safeguards help reduce unsupported conclusions, although they cannot eliminate all model errors.

I chose a small open-weight model to explore whether a useful workflow could run locally without requiring a hosted LLM API for every analysis. The trade-off is that smaller models may struggle with complex agreements and ambiguous language, so users still need to review the results.

Why Does Open Innovation Matter?

Project agreements and client conversations can contain sensitive business information. I wanted to explore an approach that gives freelancers more control over where their data is processed.

Using an open-weight model through Ollama makes local inference possible without sending every prompt to a hosted LLM API. When the frontend, backend, and model all run locally, the workflow can keep its inputs on the user's machine.

Open models also make experimentation more accessible. Developers can compare different models, inspect their behavior, modify the surrounding validation logic, and adapt the application to their own needs.

For this project, open innovation made it possible to experiment with a locally run model and build application-level safeguards around its limitations, rather than depending entirely on a closed API.

Local inference is not automatically cost-free or perfectly private: hardware and electricity still have costs, and the entire application must be configured locally to keep inputs off external services.

DEV Community: Juan Esteban Lopez Aranzazu