Gigsie: From Vague Requests to Fair Gigs — Building a Smarter Freelance Marketplace 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.

A small business owner knows what they want: more customers, a better website, improved product listings, or help with social media. But explaining that work clearly enough for a freelancer to complete it can be surprisingly difficult.

A vague request can lead to unclear deliverables, unrealistic expectations, missed deadlines, and disagreements about what was actually promised.

I built Gigsie, an AI-powered freelance micro-gig marketplace that helps small businesses turn those vague requests into structured tasks that students and beginner freelancers can understand and apply for.

Gigsie's main differentiator is FairScope. Instead of simply generating a job description, it reviews the proposed scope, identifies missing information, highlights unclear acceptance criteria, and helps the business consider different approaches before publishing.

The business can compare three strategies:

The final result is a Gig Passport: a structured task brief covering the objective, deliverables, definition of done, skills, exclusions, client responsibilities, budget, deadline, assumptions, and unanswered questions.

Students can browse published gigs, review the agreed scope, see how their listed skills match the requirements, submit proposals, complete optional practice skill assessments, and coordinate interviews through the prototype.

The idea is simple: help both sides understand the work before anyone starts.

Gigsie is an early-stage prototype rather than a production marketplace. Its current application uses local JSON storage and does not provide real authentication or a shared, production-ready multi-user database.

Try Gigsie: https://hacktoberfest-project-gigsie.streamlit.app/

The application is deployed on Streamlit Community Cloud. Live AI generation depends on the configured Groq API credentials and internet access.

GitHub repository: https://github.com/litsparks-poorvi-06/Hacktoberfest-Project-GIGSIE

The source includes the Streamlit application, AI integration, FairScope analysis, workflow and validation logic, JSON-based storage, and tests.

The repository must be publicly accessible to reviewers at submission time. Before publishing it, I checked that API credentials and private runtime data were excluded.

I built Gigsie using Python and Streamlit, with GPT-OSS ( openai/gpt-oss-20b ) served through Groq for task-brief generation.

The product combines AI-generated suggestions with deterministic Python logic.

The AI drafts the task brief and suggests ways to clarify the request. FairScope then applies structured checks to identify missing or unclear information. The business can compare alternative scopes, edit the result, and explicitly approve the final Gig Passport before publishing.

The application also includes student profiles, gig browsing, skill matching, proposals, structured practice assessments, and interview coordination.

I used automated tests to check storage, validation, workflow rules, assessment scoring, application handling, and interview state transitions. Model calls are mocked in unit tests so automated test runs do not depend on live API calls.

One important design decision was to keep the AI's suggestions separate from deterministic validation and human decisions. A model can propose a scope, but it should not silently change the business's budget, promise a result, or publish a task without approval.

I wanted to test more than whether GPT-OSS could generate a convincing freelance brief. The important question was whether Gigsie could preserve the business's constraints and identify requests that needed further clarification.

I created five synthetic business-request cases covering different freelance tasks and ran a live evaluation using openai/gpt-oss-20b through Groq. Each case made one model call.

I evaluated three structural properties: required-field completeness, preservation of the stated budget, and preservation of the stated deadline. I also tested whether FairScope detected predefined scope gaps.

The methodology, recorded outputs, and reproduction instructions are available in the FairScope evaluation report.

These results describe a five-case demonstration, not a general benchmark of AI quality. Complete fields do not necessarily mean the resulting brief is clear, fair, or achievable.

FairScope missed one expected issue in the product-listing evaluation. The evaluation case assumed the system should identify empty rows in the customer's spreadsheet, but FairScope analysed the request and the generated brief rather than the spreadsheet itself.

That failure exposed an important limitation: an AI scope reviewer cannot reliably identify problems in source materials it has never inspected.

I kept the false negative in the recorded results rather than weakening the evaluation criteria after seeing the output.

The project includes a small evaluation dataset, a runnable evaluation script, recorded outputs, and automated tests using mocked model responses. The live results were collected separately from the test suite.

The experiment is deliberately limited: five synthetic cases, one run, and no human-rated brief-quality benchmark. Further evaluation should use more cases, repeated runs, and independent human reviews.

The experiment helped me distinguish between generating a complete-looking brief and actually identifying the information a freelancer needs before starting work.

The core AI feature uses an open-weight model rather than relying exclusively on a closed model's weights.

That gives Gigsie a foundation that can be studied, adapted, evaluated, and potentially self-hosted under the applicable model license. It also leaves room to compare or replace models as the product evolves, rather than treating one model provider as the only possible implementation.

Open-weight AI is especially interesting for a product like Gigsie because task scoping is a specialised workflow. The goal is not just to generate convincing text; it is to generate a brief that is clear, consistent with the original constraints, and useful to both the business and the freelancer.

The model alone cannot guarantee that. That is why Gigsie combines model-generated drafts with deterministic Python checks and explicit human approval.

There is also an important limitation: Gigsie currently uses hosted inference through Groq and therefore requires an internet connection. It does not currently run fully offline or keep all task data exclusively on the user's device. Using an open-weight model does not automatically provide either benefit.

For me, open innovation means having more room to experiment with the model and workflow, inspect how the system behaves, and evolve the implementation as the product develops.

I'm entering the overall Hacktoberfest Open-Source AI Challenge: Week 2.

I'm not claiming an additional partner prize category because I have not integrated a partner's technology for a separate category in this submission.

Gigsie is still a work in progress, but this project has taught me to think beyond adding an AI call to an application. The more important question is how the AI can help people make better decisions, understand the limitations of its suggestions, and agree on work that is clearly defined before a project begins.