Usually：為個人理財打造 iPhone 式「高於平常」提示

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I was looking at the Battery Usage screen when I noticed something interesting: iOS wasn't showing usage as an isolated number. It was comparing what was happening today with what was usual for me.

By 7:15 PM, one screen told me:
You're using less battery today than you usually do by 7:15 PM.

It showed 21% today, compared with a 91% average.

Then I checked an individual app. WhatsApp showed 13% battery usage and reported that usage was 10% higher than over the previous seven days.

The screens answered two related but different questions: one compared overall battery use with what was usual by that time of day; the other compared one app with its own recent history. They weren't contradictory. They were different views of the same activity.

These were battery figures, not financial data. But the useful part wasn't either percentage on its own. It was the context behind it:

What is happening now, compared with what is usual for me?

I started wondering whether money could offer that same kind of context.

Not another dashboard asking me to interpret ten charts. Not another budgeting app telling me what I'm allowed to spend. And not a system that only becomes useful after I've manually categorized every transaction.

I wanted one small, timely observation that would make me look twice:
“By the 20th, you're spending 28% above your usual pace.”

That sentence became the starting point for Usually — Your Money Has Habits. Usually Knows Them.

Usually is an AI-assisted personal finance companion that works with bank and UPI statement files, looks for recurring financial patterns, compares spending against historical baselines, and helps reduce the repeated work of classifying transactions.

Its guiding principle became:

Automate the routine. Ask about the ambiguous. Remember the answer.

I wanted software that would quietly handle the repetitive work, give me evidence when something looked different, and leave decisions about my money in my hands.

The sloth is more than a decoration for the challenge theme. It represents the kind of software I wanted to build: something that doesn't demand constant attention when the routine can be handled for me.

Usually brings three connected experiences together:

• Home Briefing gives me concise observations about recurring activity and financial habits.
• Financial Analysis helps me understand cash flow, category patterns, transfers, and spending pace.
• Verified Ledger keeps the underlying transactions available to inspect rather than hiding the evidence behind a summary.

The idea is not to generate more financial information. It is to make the information that matters easier to notice.

I also wanted the product to explain itself. When money is involved, a polished observation should never have to stand in for an explanation of where it came from.

Demo

Here's the Week 3 demonstration video.

Try the live application:

The public showcase uses synthetic demo data and deterministic rules. My locally configured Gemma/Ollama setup is separate from that hosted environment; the deployed demonstration should not be mistaken for proof that every screen calls a language model.

Code

The project is open source, and the implementation is available here.

Usually — Your Money Has Habits

A quiet, local-first personal finance companion designed with a warm, editorial notebook aesthetic Themed “Slow and Steady” with a peaceful sloth identity.

Quick Links

• Live Web Application: https://usually-tau.vercel.app/
• Hacktoberfest Week 3 Submission Video
• Website Walkthrough
• Live Cloud Backend: https://usually.onrender.com/ (Health: /health)
• GitHub Repository: https://github.com/debashis-sharingan-21/usually
• Architecture Documentation: docs/architecture-audit.md

The Problem and the Solution

Understanding personal finances usually forces an unwelcome tradeoff:

1. Tedious manual spreadsheets: High maintenance friction, requiring manual categorization of cryptic bank descriptions and repetitive bookkeeping.
2. Aggressive cloud aggregators: Demand bank credentials, harvest sensitive transaction logs, and push guilt-inducing notifications.
3. Overhyped AI financial bots: Hallucinate arithmetic totals, invent psychological spending motives (“retail therapy”), and send financial data to third-party model APIs.

Usually takes a different path: “Automate the routine, ask about the ambiguous, remember the answer.”

• What Usually automates: Pure deterministic math calculates income, living expenses, transfers, refunds, and spending-pace benchmarks…

How I Built It

The most important technical decision was to keep financial calculations separate from language-model interpretation.

I didn't want an AI model inventing balances, estimating totals from prose, or silently deciding how a transaction should be treated. Instead, I gave the model a narrower job and kept financial arithmetic in deterministic application code.
Before getting into the implementation, here's how the pieces fit together. The main financial workflow stays deterministic; local Gemma assists with ambiguous merchant classifications, with a human reviewing the suggestion before it is saved.

Usually end-to-end workflow showing statement import and validation, ledger storage, deterministic financial analysis, human-reviewed Gemma merchant classification, user-facing insights, and local versus hosted deployment.

1. Start with the statement

Usually accepts supported bank and UPI statement files. It normalizes transaction information, maps the available columns, checks for incomplete rows, and identifies duplicates before the transactions become part of the ledger.

I wanted the import process to be understandable rather than a black box. Before committing a file, the interface shows the mapping and gives the user a chance to inspect the parsed records.

Once the import is complete, it reports what happened.

In this example, all 200 synthetic demo transactions were accepted, with no duplicates or rejected rows. This is a demonstration dataset, not a public upload of my personal bank statement.

2. Calculate first, explain second

Cash-flow totals, category aggregates, transfer handling, and spending comparisons are calculated through ordinary application logic.

For spending pace, the important comparison is between cumulative spending so far in the current statement month and the equivalent checkpoint in historical periods. It is not a prediction of the final month-end total.

The synthetic example in this screenshot shows spending at ₹36,389 against a historical baseline of ₹30,409 by day 21 — a difference of 19.7%.

That percentage belongs to this demo view. It is separate from the 28% observation in my personal testing story below.

The principle matters more than any single number: if a financial observation says spending is ahead of the baseline, the underlying transactions and calculation should make it possible to inspect why.

3. Ask for help when a merchant is ambiguous

Some transaction descriptions are obvious. Others are vague, inconsistent, or unfamiliar.

In the local development setup, Gemma 2B runs through Ollama and can suggest a category for an ambiguous merchant. Instead of treating that suggestion as a final decision, Usually asks the user to review it.

A user can accept a suggestion, correct it, choose another category, or leave the transaction unresolved.

Once a classification is confirmed, the application saves the decision. When a matching merchant appears again, the known classification can be reused instead of asking the model to repeat the same work.

That is the learning cycle I wanted:

Unknown merchant → suggestion → human confirmation → saved decision → deterministic reuse.

The model assists with interpretation. It does not get the final say over how a transaction is categorized.

4. Make the operating mode visible

I also wanted a way to inspect the workspace configuration rather than leave it implicit.

This screenshot shows a local development configuration. The shared demo workspace and the local model setup are distinct from the public deployment; the hosted application does not run the Ollama instance on my own machine.

The screenshots in this article were captured in different workspace and demo states. In particular, the 200-row import example and the 82-row shared read-only workspace are not meant to represent the same dataset.

5. Be honest about what is verified

I don't think a finance application should claim that every AI pathway works simply because a screen displays an AI-related label.

In my latest verification run, 100 offline backend tests passed, alongside 22 frontend unit tests. I then ran the three live-Gemma end-to-end tests separately, and all three passed. Here's the evidence.

Backend verification — 100 tests passed

The offline backend suite completed with 100 passing tests, 3 deselected, and 1 deprecation warning in 301.61 seconds.

Live Gemma verification — 3 end-to-end tests passed

I also ran the integration tests with Gemma 2B through Ollama. All three passed, covering merchant classification, the confirmation-and-learning cycle, and spending-pace provenance.

So I am not treating the UI label in a screenshot as independent proof that every spending-pace explanation was produced by the model. The distinction between deterministic calculations and model-backed interpretation is something I want the tests to establish explicitly.

For an application dealing with financial information, knowing where a result came from is part of making it trustworthy.

Why Does Open Innovation Matter?

Transaction histories can reveal more than shopping habits. They can expose salary patterns, rent payments, family transfers, subscriptions, and other parts of a person's routine.

I wanted local model execution to be a real option for merchant interpretation, rather than making a remote, closed-model API a mandatory part of that feature.

In the local setup, Gemma runs through Ollama on the developer's machine. Once the model is installed, inference can run locally without sending merchant descriptions to a remote model-inference service.

That creates a few useful possibilities:

Control over inference. I can run and test the model in my own environment instead of depending on one hosted inference provider.

A narrower AI responsibility. Gemma assists with ambiguous descriptions, while deterministic code remains responsible for the financial calculations.

Human oversight. Suggestions can be reviewed, corrected, or skipped. Confirmed decisions can then be saved and reused.

This is not a blanket claim that every deployment of Usually is completely local or automatically private. Data handling depends on the workspace, storage, and deployment configuration. The public hosted demonstration uses synthetic data and deterministic rules; the local Ollama configuration is a separate development path.

Open innovation matters here because it lets developers inspect, run, adapt, and evaluate the model behind an application. A closed API could also categorize a merchant, but local inference provides a meaningful alternative when I want more control over where that interpretation happens.

I also see this as connected to a broader goal of financial well-being. The Consumer Financial Protection Bureau describes financial well-being in terms of control over day-to-day finances, resilience to financial shocks, progress toward goals, and freedom of choice.

Usually does not claim to measure or guarantee those outcomes. Its smaller goal is to make patterns in a person's own transactions easier to understand, so they have better context for their own decisions.

The Lazy Payoff

I wanted to know whether the idea was useful beyond a nice-looking interface.

When I tested Usually with my own 90-day Google Pay statement, the file took about four seconds to parse. I had around six unfamiliar payees to review, and I worked through the suggestions in under a minute.

The spending-pace comparison showed that I was 28% above my usual pace by the 20th of the month. That made me inspect the transactions more carefully. I had mentally filed a couple of birthday gifts under “fine, one-off expenses.” Looking more closely, I found a duplicate streaming-service charge I hadn't noticed.

Usually didn't make the decision for me. It helped me notice something worth investigating.

That was the payoff I wanted: less time sorting through routine activity, and more attention for the few things that deserve a closer look. The public demo uses synthetic data; my personal statement isn't part of the public demonstration.## The Slow-and-Steady Idea

The payoff isn't a claim that Usually saves a fixed number of minutes every week.

It is the repeated work the app is designed to reduce: classifying the same merchant again, manually connecting individual transactions into a pattern, or trying to understand a spending change without seeing the evidence behind it.

Usually aims to handle the routine, ask when interpretation is uncertain, and remember a choice only after it is confirmed.

That is the part of open-weight AI I wanted to explore. Not AI making every decision, but software becoming more helpful without becoming less accountable.

Prize Categories

Best Use of Gemma (featured category) — Usually uses the open-weight Gemma 2B model through Ollama to suggest categories for ambiguous merchants in the local setup. Suggestions require human review, and confirmed decisions are saved and reused deterministically.

Best Use of Render (featured category) — Usually's FastAPI backend is deployed as a Render web service. The Vercel-hosted frontend routes /api/* requests to the Render backend.

Live backend:

Health endpoint: https://usually.onrender.com/health

Let's Discuss

What is one repetitive task in your life that you wish could quietly take care of itself?

And, when software handles the routine, which decisions would you still want to review yourself?

I'd especially appreciate feedback on the balance between local AI assistance, deterministic financial logic, and human control in an application that works with sensitive information.

Usually — Your Money Has Habits. Usually Knows Them.

Automate the routine. Ask about the ambiguous. Remember the answer.

Slow and steady. 🦥