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

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

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

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.

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.

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.

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

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

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.

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:

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.

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.