Ledger: A Small-Business Finance Tracker with Groq-Hosted 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.

Ledger is a small-business finance tracker and AI pricing assistant for solo business owners and freelancers. It helps users record income and expenses, review business totals, and estimate prices for products or services.

The Price Calculator keeps saved estimates separate from actual financial transactions. Users can calculate a price, review it, and save it as a pricing record. Saved prices can be searched, filtered, viewed, edited, deleted, or reused as calculator inputs. Reusing a record prefills the form but does not restore its old result; users must calculate again before saving a new price.

Ledger is aimed at small business owners who want a simpler workflow than a full accounting suite.

The frontend uses React, TypeScript, Vite, and Tailwind CSS. The backend is an Express and TypeScript API backed by MongoDB Atlas through Mongoose.

Both AI flows use the same Groq client and configured model. The server uses the OpenAI SDK with Groq's OpenAI-compatible endpoint:

new OpenAI ({ apiKey, baseURL: " https://api.groq.com/openai/v1 ", }); Enter fullscreen mode Exit fullscreen mode The default model ID is openai/gpt-oss-120b. “OpenAI-compatible” describes the API protocol; inference requests go to Groq. This is hosted inference, not local inference, and the user's submitted text is sent to Groq.

For transaction entry, Ledger asks the model for JSON-formatted drafts, then validates the response on the server and checks whether amounts and dates are supported by evidence in the user's original text. Drafts are not saved automatically; the user reviews and confirms them. For pricing, the model offers qualitative advice around the deterministic calculation. The application validates the recommendation, while financial arithmetic remains ordinary application code.

(unit cost + additional costs per unit) × (1 + markup percentage / 100) Enter fullscreen mode Exit fullscreen mode Saved prices have a dedicated Mongoose model and business-scoped API rather than being stored as transactions. One limitation: Ledger does not yet authenticate users or establish business ownership. A business ID scopes a request but does not prove that its caller owns the business, so this prototype should not be exposed as a private multi-user finance service until authorization is added.

Using an open-weight model gives Ledger another option beyond a proprietary model endpoint, and the OpenAI-compatible API meant the server could keep its existing client shape while switching inference providers. That is useful flexibility, but it is not the same as running the model locally or keeping data on the user's device. This version sends text to Groq, and I have not measured inference costs, extraction quality against other models, or customer willingness to pay.

I also keep the boundary between model interpretation and financial decisions explicit: the model can help interpret language and suggest pricing context, but application code calculates prices, validates model output, and leaves consequential saves under user control.

This earlier session captures the Saved Prices work discussed here; it predates the switch to Groq:

Building Ledger's Saved Prices and Preparing a Hacktoberfest Post You Extend Ledger's saved-pricing feature with a dedicated business-scoped Saved Prices page: retrieve and filter real pricing records, show details, reuse stored inputs in the calculator, and support editing and confirmed deletion without touching transactions.

The existing pricing-record model and business-scoped GET/POST endpoints were reused. The Saved Prices page adds search and type/currency filters, detail views, calculator prefill without restoring an old result, direct record edits, and confirmed deletion. Business-scoped PATCH/DELETE routes validate updates and keep pricing records separate from transactions. Typechecks, production builds, 47 server tests, and a mobile browser check passed. The application still has no authentication or business-ownership layer, so IDs scope records but cannot prove requester ownership.

How should Mastra be included in this project? Plan an integration.

The proposed scope is the transaction-drafting flow only: use a bounded Mastra workflow for structured extraction while preserving Ledger's existing Zod schema, evidence-grounding checks, response contract, and review-before-save behavior. Do not give the model transaction or database tools.

Check current Mastra package versions against Ledger's documented Node support floor and inspect dependency audit findings. Output Latest @mastra/core 1.78.0 requires Node >=22.13. Latest stable version compatible with Node 20 is 0.24.9; npm audit reports 6 high and 32 moderate vulnerabilities, with fix requiring the major upgrade. You Keep Node 20 support and defer Mastra integration.

Mastra was not retained as a dependency and no repository feature changes were made for this integration. The future option is to revisit the workflow when the runtime floor can move to Node 22.13+ or a safe compatible Mastra release is available.

Prepare a DEV post using the Hacktoberfest Week 2 Side Hustle structure and include an agent session.

The current code uses an OpenAI-backed parser and has no Mastra integration, so the Week 2 open-source AI eligibility should not be claimed. The user requested an honest project post using the challenge structure, not an eligible submission claim.

Based on the implemented technology and available project evidence, these are the partner categories I can substantiate: