DEV Community: Adarsh Negi

FreelanceFlow: A Private AI Assistant for Freelancers

Adarsh Negi — Tue, 20 Oct 2026 12:34:02 +0000

FreelanceFlow: A Private AI Assistant for Freelancers

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

What I Built

Freelancers shouldn't need to spend their evenings organizing receipts, extracting invoice details, and preparing expense reports.

That's why I'm building FreelanceFlow — a local-first AI assistant that helps freelancers organize their financial documents without relying on a cloud-based AI API.

The idea is simple: drop in an invoice or receipt, let AI extract the relevant information, review the results, and export organized records for accounting.

FreelanceFlow is designed to help independent developers, consultants, and small business owners manage repetitive administrative work so they can spend more time on the work that actually pays.

The planned core features include:

Smart document extraction: Extract vendor names, dates, amounts, taxes, and currencies from invoices and receipts.
Expense categorization: Organize transactions into useful expense categories.
Human-in-the-loop verification: Review extracted information before it enters your records.
Exportable reports: Turn scattered documents into structured CSV data for bookkeeping.
Local-first processing: Keep sensitive financial documents on the user's own machine.

The business model is straightforward: a small, affordable desktop application for freelancers who want to save time without paying for another recurring AI subscription.

Demo

[Add your deployed demo or a short screen-recording link here.]

The demo will show the workflow from importing a document to reviewing extracted fields and exporting structured records.

Code

GitHub Repository — FreelanceFlow

Replace this placeholder with the actual repository URL before publishing.

How I Built It

The central design decision is to use open-weight AI as a core part of the application rather than treating it as an optional feature.

My planned stack includes:

Ollama: Runs the language model locally.
Gemma 3 4B: Provides local inference for document understanding and expense categorization.
Python and FastAPI: Handle document processing, validation, and application logic.
PyMuPDF and OCR tools: Extract text from PDFs and scanned receipts.
SQLite: Stores structured expense records locally.
React and TypeScript: Power the user interface.

The architecture separates probabilistic AI tasks from deterministic financial operations. The model assists with interpreting documents and assigning categories, while Python validates fields and performs calculations.

That distinction matters. A plausible-looking AI response is not necessarily an accurate financial record, so extracted values need validation and a review step before being accepted.

The goal is to keep the workflow useful, transparent, and accessible on consumer hardware.

Why Does Open Innovation Matter?

For FreelanceFlow, open innovation isn't just a technology preference. It directly influences whether the product makes sense as a small business tool.

1. Privacy by design

Invoices can contain client names, addresses, payment details, and commercially sensitive information. Running inference locally makes it possible to process these documents without sending their contents to an external AI inference provider.

2. More predictable operating costs

A freelancer processing hundreds of documents shouldn't necessarily need to pay an AI API provider for every extraction. Local inference avoids per-request model API charges, although hardware, development, and distribution still have costs.

3. Freedom to experiment

Open-weight models give developers more control over model selection, prompting, evaluation, and deployment. If a different model performs better on scanned invoices or unfamiliar currencies, the application can be adapted without being tied to one proprietary API.

4. A product that can work without a permanent cloud dependency

Once the model and required components are installed, the core workflow can be designed to operate offline. That can make the tool more useful for people who want their financial records to remain under their control.

There are trade-offs. Local models require suitable hardware, and extraction accuracy must be tested across different document formats. A smaller model may also need more careful prompting and validation than a larger hosted model.

But for a focused task like invoice organization, the ability to control data flow, inference costs, and model choice is a meaningful advantage.

My takeaway: Open-source AI makes it possible to build a small, specialized product without automatically inheriting the recurring costs and data-sharing assumptions of a hosted AI service.

My First User

The next milestone is to put FreelanceFlow in front of a freelancer who regularly handles invoices and receipts.

I'd like to measure three things:

How much time does it save compared with manual entry?
How often does the user need to correct extracted fields?
Would the user pay for a tool that makes this process faster and keeps their documents local?

I haven't included fabricated testimonials or payment claims. The goal is to validate the product with a real user and let their feedback determine what gets built next.

Prize Categories

[Add the applicable partner categories based on the challenge's official rules and the technologies actually used.]

TrailMate

Adarsh Negi — Mon, 12 Oct 2026 05:54:31 +0000

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

TrailMate 🌿 — Let AI Plan Your Next Adventure

What I Built

TrailMate is a local-AI-powered outdoor exploration companion designed to turn screen time into real-world experiences.

We spend so much time looking at screens that even our breaks often involve another screen. TrailMate takes a different approach: use AI to help you step outside, explore your surroundings, and pay attention to the world around you.

Users can choose their preferred environment, difficulty level, and mission duration. TrailMate then generates a structured outdoor exploration mission with three objectives, including visual discovery and mindful observation activities.

Whether you're walking through a neighborhood, visiting a park, or exploring a nature trail, TrailMate gives you a small reason to look beyond your phone.

The idea behind it is simple:

Use technology to get people away from technology.

TrailMate is being built with local AI at its core, so the experience doesn't have to depend on sending every request to a closed, cloud-hosted AI API.

Demo

The current development version runs locally, with a FastAPI backend, a Next.js frontend, and Ollama powering local AI inference.

I'll share a demonstration of the mission-generation flow here.

Code

The project uses a modular architecture:

Frontend: Next.js, React, TypeScript, and Tailwind CSS.
Backend: Python and FastAPI.
Open-source AI: Gemma 3 4B through Ollama.
Validation: Pydantic schemas to validate generated mission data.
Testing: Pytest for backend tests and Node's test runner for frontend API tests.

The frontend communicates with the backend, while the backend handles AI requests and validates the generated output.

How I Built It

I built TrailMate incrementally, starting with the backend and local AI integration before building the mission-generation interface.

The AI component uses Gemma 3 4B through Ollama, running locally rather than relying on a closed, hosted language-model API.

When a user submits their preferences, the frontend sends a request to the FastAPI backend. The backend constructs a prompt, requests structured JSON output from the model, and validates the response against Pydantic schemas before returning the mission.

The current implementation includes:

Customizable mission duration, difficulty, and environment.
AI-generated missions containing exactly three objectives.
Structured response validation and error handling.
A responsive interface with loading and recovery states.
Automated backend and frontend tests.

Running local inference on my laptop has also introduced an interesting engineering challenge: balancing generation time with a usable experience on CPU-only hardware. That has made timeout handling, error recovery, and realistic performance expectations important parts of the project.

TrailMate is still under development. Photo-based objective verification, persistent mission progress, and a discovery journal are planned extensions rather than features I'm claiming as complete.

Why Does Open Innovation Matter?

Open innovation is what makes TrailMate possible as an experiment I can build, understand, and improve independently.

Using an open-weight model with local inference gives me the freedom to explore AI without making a proprietary API a mandatory part of the core experience. It also gives me more control over how inference is run and how data flows through the application.

There are trade-offs. Local models can be slower on limited hardware, and building a reliable application requires more than simply calling a model. I still need validation, sensible error handling, and a user experience that accounts for those limitations.

But that's part of the opportunity: open AI makes it possible to experiment with ideas, learn from the entire stack, and build tools that can run closer to the people using them.

For TrailMate, that matters because the product is about reconnecting with the physical world. Local inference is a step toward making that experience less dependent on cloud infrastructure.

My Agent Session

Optional: I'll add my development session here if I publish one through DevRelay.

TrailMate is a work in progress, but the first core loop is taking shape: choose your surroundings, generate a mission, and go explore.

The goal isn't to make people spend more time using TrailMate. It's to give them a good reason to put their phones away.

🌿 Build with AI. Explore the real world. Touch grass.

SpeakUp

Adarsh Negi — Mon, 05 Oct 2026 02:51:03 +0000

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

What I Built

I built SpeakUp, a local AI-powered mock interview coach for my friend Ayan.

Ayan is preparing for placements and has a frustrating problem: he knows the answers, but struggles to communicate them during interviews.

When we discuss technical topics normally, he can explain them well. But when placed in an interview-like situation, he tends to hesitate, use filler words, lose structure, and struggle to communicate his thoughts clearly.

So I built SpeakUp specifically for him.

Instead of simply giving him interview questions and showing the "correct" answer, SpeakUp acts as an interviewer:

Question → Ayan answers → AI evaluates → Follow-up question → Feedback

The system evaluates things such as:

Clarity
Relevance
Answer structure
Filler-word usage
Completeness
Communication quality

It then gives actionable feedback and continues the interview with a follow-up question.

The goal isn't to teach Ayan what to say.

It's to help him communicate what he already knows.

Demo

🌐 Live Demo: [NO DEPLOYED LINK]

Here's a short example of an interview session:

Interviewer: Explain the difference between a process and a thread.

Ayan answers the question.

SpeakUp then analyzes the response and provides feedback such as:

Clarity        7/10
Relevance      9/10
Structure      5/10
Communication  6/10

Filler words:
"um"           × 4
"actually"     × 2

Suggestions:
→ Start with a concise definition.
→ Compare the two concepts explicitly.
→ Finish with a concrete example.

It then asks a follow-up question instead of ending the conversation.

Code

💻 GitHub: [NO GITHUB REPOSITORY]

The project is built with Python and is designed to run locally.

How I Built It

The core of SpeakUp is an open-weight AI model running locally rather than a closed AI API.

The current stack is:

Python — application logic
Streamlit — user interface
Ollama — local model inference
Gemma — open-weight language model
Git/GitHub — source control and project distribution

The basic architecture looks like this:

                ┌───────────────────┐
                │    SpeakUp UI     │
                │    Streamlit      │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │ Interview Engine  │
                │     Python        │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │      Ollama       │
                │  Local Inference  │
                └─────────┬─────────┘
                          │
                          ▼
                ┌───────────────────┐
                │      Gemma        │
                │   Open-weight AI  │
                └───────────────────┘

The model generates interview questions, evaluates responses, provides feedback, and generates follow-up questions.

The application is designed around the model rather than using AI as an additional feature.

Why Does Open Innovation Matter?

Interview practice can involve personal information: a student's projects, weaknesses, communication difficulties, career plans, and the answers they give during practice sessions.

I didn't want Ayan's interview practice to depend entirely on sending that information to a closed API.

With a local open-weight model, the core interaction can happen directly on the user's machine.

Closed API

Ayan
  ↓
Application
  ↓
External API
  ↓
Closed model
  ↓
Response


SpeakUp

Ayan
  ↓
SpeakUp
  ↓
Local inference
  ↓
Open-weight model
  ↓
Feedback

Open models also give developers more control.

I can experiment with different models, change prompts and evaluation strategies, run inference locally, and potentially fine-tune the system for interview practice without redesigning the entire application around a proprietary API.

For this particular project, open innovation isn't just about using an open model because the challenge asks for it.

It directly supports the problem I'm trying to solve:

private, controllable, locally-run interview practice.

My Agent Session

I used the session to document the development process and show how the project evolved from the initial idea into the final application.

What Ayan Thought

After building the first version, I gave it to Ayan and asked him to actually use it for a mock interview.

[ADD ACTUAL EXPERIENCE / QUOTE FROM AYAN]

The most interesting part wasn't whether the AI could answer interview questions.

It was whether it could help Ayan answer them better.

That's what I wanted to test.

What I Learned

Building SpeakUp changed how I think about AI projects.

It would have been easy to build another chatbot that asks questions and generates answers.

But the real problem wasn't:

"How can AI answer interview questions?"

It was:

"How can AI help someone communicate knowledge they already have?"

That distinction shaped the entire project.

It also showed me one of the practical advantages of open-weight AI: the model can become part of the application architecture rather than simply being an external API that the application calls.

About me !

Adarsh Negi — Sun, 04 Oct 2026 10:10:45 +0000

Hey everyone! 👋

I’m Adarsh, a CSE student from India. I’m currently focused on backend development, Python, DSA, and open source.

I’m starting to explore open source and looking forward to making my first meaningful contributions.

I joined DEV.to to document my learning journey, connect with other developers, and hopefully learn from the amazing community here.

Looking forward to building, contributing, and learning along the way!