I Built a Private AI Bookkeeper for Freelancers — Without Depending on a Proprietary AI API

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

tags: devchallenge, hf26challenge, ai, opensource

This is a submission for the "Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle" ( https://dev.to/challenges/hacktoberfest-week2-2026-10-12 ).

Your Invoices Are Nobody Else’s Business: Building a Local-First AI Bookkeeper

Imagine finishing a month of freelance work, opening a folder full of invoices and receipts, and realizing that your next task is to manually organize every single document.

Extract the vendor name. Find the invoice date. Identify the total. Categorize the expense. Check for missing information.

For freelancers and small business owners, this is the kind of administrative work that quietly eats into time they could spend doing actual work.

AI can help automate it. But what if the documents contain sensitive financial information? And what happens when the cost of using an AI API starts eating into the savings from automation?

That got me thinking: Can I build a useful AI bookkeeping assistant that gives freelancers more control over their data, their costs, and the technology they depend on?

That’s the idea behind BillBuddy Local, my project for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

The project is currently in development, and this is the problem I’m setting out to solve.

BillBuddy Local is a planned privacy-first AI assistant that helps freelancers, independent consultants, and small businesses turn invoices and receipts into organized financial records.

Instead of manually copying information from document to spreadsheet, the goal is to make the process as simple as uploading a document and reviewing the extracted information.

The goal isn't to replace accountants or let an AI make financial decisions without supervision.

It's to eliminate repetitive data entry while keeping people in control of their records.

I'm starting with a specific audience: freelancers, solo consultants, independent creators, and small agencies that regularly handle invoices but don't need an expensive enterprise accounting platform.

The business model I'm exploring is a free local version, with potential paid features such as batch processing, team workflows, additional export formats, and optional hosted deployment.

My initial pricing hypothesis is ₹299–₹799 per month, depending on the features and usage limits.

That price isn't validated yet. One of my goals is to get the product in front of potential users and find out whether the time saved is valuable enough for them to pay for it.

A side hustle needs more than a clever technical implementation. It needs a problem people actually want solved.

I'm working toward an end-to-end demo that shows a sample invoice being processed, the extracted fields being reviewed, and the final record being exported.

I'll add the working demo link here once the application is ready.

GitHub repository: "Fiza-Naaz339/BillBuddy"

I'm developing the project in the open so that the implementation, technical decisions, and future improvements can be inspected and reproduced.

As development progresses, I'll document the setup instructions, model configuration, sample documents, and tests needed to run the application.

I don't want BillBuddy Local to be another chatbot that simply reads a document and returns a paragraph.

I want to build a document-processing pipeline where each component has a clear responsibility.

These are the technologies and architectural choices I'm working toward; the complete pipeline is not implemented yet.

One principle I want to follow throughout the build is that the language model shouldn't be responsible for everything.

OCR can handle text recognition. The model can interpret the extracted text and propose structured fields. Deterministic code can validate predictable rules. The user can resolve uncertainty.

Separating these responsibilities should make the system easier to test, debug, and improve.

A polished interface isn't enough to prove that an AI document-processing tool is useful.

Once the pipeline is implemented, I want to evaluate it against a set of manually verified invoices and receipts.

The measurements I'm interested in include:

I'd also like to compare the chosen open-weight model against a baseline using the same documents and evaluation rules.

I haven't collected these results yet. I'd rather measure actual performance than claim improvements based on assumptions.

For this project, open innovation isn't just a technology preference. It could change the economics and privacy options available to the people using the product.

Invoices and receipts can contain personal information, business relationships, addresses, and tax details.

My goal is to support a local-first workflow in which document processing can happen on hardware controlled by the user.

That requires more than running the language model locally. OCR, storage, logs, and other processing must also be configured appropriately if the entire workflow is to remain local.

For users who prefer a hosted experience, deployment and data-handling choices will need to be clearly documented.

A product aimed at freelancers needs sustainable economics.

If every processed invoice requires a paid proprietary API call, the cost structure depends partly on another provider's pricing and usage limits.

An open-weight model gives me the option to investigate local inference or self-managed hosting, depending on the model's hardware requirements and the needs of the customer.

Open-source AI isn't automatically free. Hardware, hosting, maintenance, and development still have costs. The advantage is having more flexibility over how those costs are managed.

Different models have different strengths, resource requirements, and performance characteristics.

An open-weight approach gives me room to evaluate alternatives, experiment with inference runtimes, and optimize the pipeline for the invoice formats my users actually encounter.

If a smaller model provides sufficient accuracy at lower operating cost, I can investigate using it. If a model struggles with certain documents, I can compare alternatives using the same evaluation set.

The goal is to choose based on evidence rather than being locked into one provider's ecosystem.

Invoices vary across vendors, industries, and countries.

An open codebase could allow other developers to contribute document parsers, validation rules, language support, integrations, and evaluation datasets.

I want this project to be something developers can inspect, learn from, and adapt to their own use cases.

For me, open innovation means more than making source code available. It means giving people the flexibility to understand and improve the tools they rely on.

My immediate priority is to turn the idea into a working end-to-end application.

The final step matters just as much as the technical work.

I want to find out whether the application actually saves time, which errors users care about most, and which features would make it useful enough to pay for.

I don't have a validated customer or measured performance results to share yet. Those are things I want to earn through implementation and real-world testing.

My measure of success won't be how many AI features I can fit into the application.

It will be whether someone can finish their bookkeeping faster, review the results with confidence, and maintain control over their financial documents.

That's the side hustle I'm working toward: practical AI, built with openness and user control at its core.

Prize Categories Best Use of Gemma: If Gemma actually powers the document-processing workflow. Best Use of Render: If Render is genuinely used for the application or AI runtime. Best Use of Tiger Data: If Tiger Data/pgvector is actually part of the implemented solution. Best Use of Sentry Agent Tracing: If Sentry's relevant agent-tracing capabilities are integrated and you can show the resulting traces.