This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Three haircuts can make for a busy day. But a busy day does not automatically tell a barber how much money is available to spend tomorrow.
Imagine two customers pay R50 each in cash, a third pays R50 by card, and the barber spends R20 on supplies.
That is R150 in recorded sales, but it isn't necessarily R150 in available cash. The card payment might not have settled. Rent may still be due. Other business expenses might be missing.
That distinction inspired KasiMargin, a local-first financial-clarity prototype for South African owner-operated microbusinesses.
The idea grows out of a broader question I've been exploring through KasiLink and Kopano Labs: how can small businesses turn the information they already have into better-informed decisions, without needing complicated accounting software?
KasiMargin currently offers two connected experiences:
The application distinguishes estimated operating margin from conditional cash headroom. When important evidence is missing, the result remains UNKNOWN/HOLD, rather than quietly treating an unknown amount as zero.
Our latest interface improvement also makes the decision explanation visible, connects the two workflows through simple navigation, and displays previously recorded daily totals as a read-only reference. Recorded sales are never automatically promoted into independently verified cash.
Who might pay for this? An owner-operated barber shop, spaza shop, car wash or food business that finds daily financial clarity useful enough to return to. That is our proposed customer, not a proven commercial result. We have not yet completed a real operator trial or demonstrated willingness to pay.
Watch the 97-second synthetic KasiMargin demonstration The recording demonstrates actual local browser interaction with fictional barber records: entering sales, recording spending, correcting an amount and inspecting the separate financial-check workflow.
Correcting one R50 cash haircut to R60 changes recorded sales from R150 to R160 while retaining the earlier entry's history.
The video has captions and no audio. It was recorded before the latest interface improvement and demonstrates the earlier deterministic explanation experience. It is not a recording of new live Gemma inference.
The project was created during the October 12–18 challenge window.
The submitted source baseline is main@85d3cc9, with a successful GitHub Actions run.
The latest operator-experience improvements were introduced through PR #8, followed by documentation alignment in PR #9.
The project code is MIT-licensed. Gemma model weights remain subject to their own terms. Development involved AI-assisted coding, and this is a solo project submission.
KasiMargin combines:
An important design decision is that Gemma does not perform the financial arithmetic.
The financial engine computes values using exact integer cents, handles incomplete evidence and produces required warnings. Gemma receives a permitted catalogue of facts, warnings and possible actions, then selects identifiers within that catalogue.
Its selections undergo validation before a trusted renderer produces the final explanation. The model cannot invent new amounts, change ledger entries or authorise purchases. If inference fails, the system uses a clearly labelled deterministic fallback.
We completed a recorded local evaluation across seven synthetic financial scenarios, with three model calls per scenario.
The results were:
In that scenario, Gemma selected preserve_headroom but omitted another permitted action, compare_restock_quote. Required financial amounts and warnings remained unchanged.
These results demonstrate bounded local inference, not proven improvements in financial understanding.
The recorded warm median inference time was approximately five seconds, while the cold median was approximately 89 seconds. This exposes a real hardware and responsiveness trade-off.
Read the complete Gemma technical evaluation. A financial-clarity application for a small business should be inspectable, reproducible and careful about the information it is trusted with.
Running an open-weight model locally gives us a way to experiment with explanations without sending the inference payload to a hosted model API. It also lets us compare model behavior against deterministic output, identify failures and question whether the AI genuinely adds value.
There are trade-offs. Local model weights require storage and memory, cold inference can be slow, and an open model does not automatically produce better financial guidance.
For KasiMargin, open innovation matters because it allows us to investigate personalized intelligence while keeping financial calculations, provenance and human decision authority separate. The first interface was too technical. It displayed financial terminology and implementation details before answering what the business operator actually needed to understand.
The later design moved toward everyday tasks, visible financial explanations and a more direct connection between recording activity and reviewing money.
But I want to take the product further.
South African microbusinesses operate across different languages, sectors and working conditions. My longer-term direction is to investigate visual-first, accessible and context-aware financial intelligence, with optional language and voice support where those capabilities genuinely help.
That direction is not implemented functionality today.
The next important experiment is a consented operator walkthrough. Can a barber record a sale, correct a mistake and explain the difference between recorded sales and available money without coaching? Does the experience fit their working routine? Does Gemma's explanation improve understanding compared with the deterministic version?
Those are questions for real users, not assumptions we can settle with synthetic tests.
KasiMargin does not currently verify bank balances or card settlement, scan receipts, provide unrestricted financial advice or demonstrate measurable economic impact.
The purpose of this first version is to build a trustworthy foundation for financial understanding, then allow the people who use it to help shape what comes next.
Best Use of Gemma
KasiMargin includes a locally evaluated Gemma 4 E2B integration with constrained output selection, explicit validation and deterministic fallback. Its incremental benefit to operator comprehension remains unmeasured.