Building Finnear: A Technical Deep Dive into Smart Financial Tracking

Hey there! I'm building Finnear, a financial tracking app for bootstrapped founders, and I wanted to share how some of the core features work under the hood. If you're a fellow SaaS founder who gets excited about implementation details, this one's for you.

Smart Categorization Without Breaking the Bank

One of the biggest pains with financial tracking apps is categorization. You've got hundreds of transactions, and manually sorting them is soul-crushing. AI can help, but calling an LLM for every single transaction? That's a great way to rack up API costs real fast.

Here's what I do instead: intelligent caching at the merchant level.

When a transaction comes in, I grab the merchant name and check the merchant table first. If I've seen "Stripe" or "AWS" or "Vercel" before, I already know what category it belongs to. Boom, instant categorization, zero AI calls.

But when I encounter a new merchant? That's when I send it to the AI. I give it the merchant name and let it figure out whether this is software, hosting, marketing, or whatever category makes sense. Then (and this is the key part) I store that mapping in the database.

So the first "Acme Coffee Shop" transaction costs me an AI call. Every subsequent transaction from Acme Coffee Shop? Free. The system gets smarter and cheaper over time.

This approach means I'm only paying for AI when I actually need it, and for most users, after the first month or so, the majority of transactions are auto-categorized without touching the AI at all.

Bank Connections with Plaid: A Webhook Dance

For bank connectivity, I'm using Plaid, which is pretty much the standard for US financial data (and why I'm US-only for now). But here's the thing: Plaid doesn't work quite how you might expect if you haven't used it before.

The flow goes like this:

1. User authenticates in Plaid Link. They go through Plaid's UI, enter their bank credentials, do the MFA dance, all that fun stuff.

2. First webhook: "Hey, they're connected!" Plaid hits my webhook endpoint to let me know the authentication was successful. At this point, I've got an access token and can technically fetch data, but Plaid recommends waiting.

3. Second webhook: "Initial transactions ready". This is where the magic happens. Plaid processes the account and sends me another webhook when the initial transaction data is ready. I fetch historical transactions (usually 2 years depending on the bank), grab current balances, and populate the user's account.

4. Ongoing webhooks: "New stuff!" After that, Plaid continuously monitors the account and sends me webhooks whenever there are new transactions. I fetch and import them automatically.

The webhook architecture is actually pretty elegant once you wrap your head around it. I'm using Convex for my backend, so webhooks come in, I validate them, and then I kick off background jobs to fetch and process the transaction data. No polling, no manual syncing. It just works.

Rule-Based Automation (The Secret Sauce)

Okay, this is my favorite feature, and it's one of those things that seems obvious in hindsight but took a while to get right.

The problem: You import 200 transactions from your bank. You go through and fix a few categories, update some merchant names to be cleaner (because banks send messy data like "AMZN MKTP US*2X3Y4Z"). But then next month, you're doing the same manual work all over again.

The solution: automatic rule creation with a single click.

Here's how it works:

When you change a transaction's category or merchant, I pop up a toast notification: "Want to create a rule for this change?" One click, and boom. I've created a rule that says "if the imported transaction name contains 'AMZN MKTP', automatically set the merchant to 'Amazon' and category to 'Software'."

Behind the scenes, I'm storing pattern-matching rules that run on every new imported transaction. The rules check against the raw transaction description that comes from the bank (before any cleanup), and if there's a match, I automatically apply the category and/or merchant.

You can also manually create rules if you want more control. Say you want all transactions containing "GITHUB" to automatically go to your Software category with "GitHub" as the merchant. Just create the rule once, and it applies forever.

This is one of those features that compounds in value. The more you use the app, the more rules you have, and the less manual work you need to do. After a few months, most of your transactions are automatically categorized and cleaned up before you even see them.

Why These Details Matter

I'm building Finnear specifically for founders like us. People who care about sustainability metrics more than traditional burn rate calculations. We want to know: "Am I actually making money?" and "When will I break even on my invested capital?"

But we're also busy. We're writing code, talking to customers, shipping features. The last thing we want is to spend hours each month manually categorizing transactions.

So every technical decision in Finnear is optimized for two things:

1. Accuracy, because financial data is not the place to cut corners

2. Automation, because founder time is precious

The AI caching keeps costs down while maintaining intelligence. The Plaid webhook architecture means data stays current without manual intervention. And the rule system learns your preferences and applies them automatically.

---

Finnear is live. Sign up at finnear.app

I also post frequently on Threads about #BuildInPublic: threads.com/@igoramidzic