The Validation Experiment

I kept it simple. Created a landing page with a waitlist signup form and started sharing it everywhere I could think of. My main channels were Threads, X (Twitter), and Reddit, places where founders and bootstrappers hang out.

I posted screenshots of mockups, talked about the problem I was solving, and dropped the waitlist link. No paid ads. No fancy marketing campaigns. Just authentic posts about what I was building and why it mattered.

Within a few days, I had about 15 email signups.

That might not sound like much. But for a pre-launch product with zero following it was enough signal. These were people who didn't know me, had never used the product, and were still willing to give me their email address. That told me something.

So I started building.

What Is Finnear?

Finnear is a financial tracking app built specifically for bootstrapped startup founders. Not the VC backed, burn rate obsessed founders. The ones who are funding their businesses themselves and care more about sustainability than hockey stick growth.

If you're a solo founder or small team maintaining a dedicated business bank account, Finnear helps you track the metrics that actually matter. Like whether you're profitable yet. When you'll break even. How much of your own money you've put into the business. Your monthly sustainability gap.

Instead of focusing on runway (how long until you run out of VC money), Finnear tracks things like total capital invested, average monthly spending versus revenue, and months to profitability. It's built for founders who are playing the long game. Not the fundraising game.

The Name: Finnear

The name came from two places. First, "Finn" for financial. Second, I wanted something that felt close to Linear, the project management tool I use and love.

Why Linear? I'm not just inspired by their product philosophy. I'm targeting their users.

If you use Linear to manage your startup's projects, there's a good chance you care about clean UI, thoughtful UX, and tools that get out of your way. Those are exactly the kinds of founders I'm building Finnear for. People who appreciate good design. Who want their financial dashboard to feel as polished as their task board.

I'm deliberately making Finnear's UI look and feel similar to Linear. Not copying it, but making it familiar. If you love Linear's aesthetic, you should feel right at home in Finnear. The spacing, the typography, the subtle animations. The dark mode that actually looks good. It's all designed to feel like it belongs in the same family of tools.

The Plaid Limitation: US and Canada Only (For Now)

One of the biggest constraints I'm working with is Plaid. It's how Finnear connects to your bank account to pull transactions and balances automatically. Problem is, Plaid primarily works in the US and Canada.

That means, at least initially, Finnear is limited to those markets. It's not ideal. There are bootstrapped founders all over the world who could use this. But it's the reality of building with the tools available. Maybe in the future I'll explore alternatives for other regions. For now, I'm focusing on where I can deliver the best experience.

What's Next: The Real Validation

Here's the thing about those 15 email signups. They were encouraging. But they weren't the full picture. People signing up for a waitlist is one thing. People actually using the product is something else entirely. People paying for it is the real validation.

As of writing this, I have zero users and zero paying customers.

That's why the next phase is critical. I'm going all in on marketing. Not to build hype or chase vanity metrics, but to get Finnear in front of the right people and see if they'll actually pay $10/month for it.

I need to validate this one more time. If I can get some paying users, people who find enough value in Finnear to pull out their credit cards, then I know I'm onto something. If I can't, then it's time to move on to the next project.

That might sound harsh. But it's the bootstrap reality. You can't keep pouring time and energy into something that isn't working. You have to be willing to call it and try something else.

Building in Public, One Step at a Time

I've been sharing the journey on Threads (where I've built up about 800 followers) by posting regular screenshots and videos of what I'm building. It keeps me accountable. And it's already generated those initial waitlist signups.

The sustainability dashboard is almost done. Average monthly spending and revenue, total capital invested, break even calculations, months to profitability. All the core features that make Finnear different from generic accounting software.

I'm rolling out beta access slowly. One or two developers at a time, fixing bugs as they come up. Once the dashboard is solid, it's time to open the floodgates (or at least crack them open) and see what happens.

I'm about to find out if people will pay for Finnear.

If you're a bootstrapped founder who's tired of financial tools built for the VC crowd, I'd love for you to try it. Sign up at https://finnear.app and I'll get you in as soon as it's ready.

And if you're building your own thing, remember this. Validation isn't just about signups. It's about whether people will actually pay you. Everything else is just noise.

The Email Provider Decision

I needed to send transactional emails to users, specifically daily digest emails that show upcoming recurring transactions per organization. Something like "Hey, here are your 3 upcoming recurring transactions" with actual data pulled from the backend.

I already use Loops for my other app, Kualia, and I really like it. It's clean, simple, and works great for what I need there. So naturally, I started looking at using Loops for Finnear too.

But I hit a wall pretty quickly. I couldn't figure out how to create custom transactional emails with dynamic lists in Loops. I needed to loop through transactions (ironically, no pun intended) and display them in the email. The Loops dashboard didn't seem to have a way to handle repeating elements filled with backend data. It's great for simpler transactional emails, but this specific use case just wasn't clicking for me.

Enter Resend

That's when I decided to give Resend a try. Two things made it appealing:

First, Convex has first party support for Resend. Since I'm already using Convex for the backend, having that native integration meant less setup and configuration on my end.

Second, and more importantly, Resend lets me build the HTML email completely on the backend. I can fetch a list of recurring transactions, loop through them in my backend code, construct the HTML with all the data, and send it off. Total control over the email structure and content.

So I went with Resend, and it's been working really well. I can now send those daily digest emails with actual transaction lists, formatted exactly how I want them.

Trying Out Cursor 2.0

I've been using Claude Code for about 6 months now, paying $200/mo for it. It's been solid for delegating coding tasks when I don't want to get into the weeds of implementation details. Really good for when you just want something built and don't need to understand every line of code being written.

But I decided to give Cursor 2.0 a try with their new Composer 1 model, and honestly, it's doing a really good job. I'm currently on the $20 plan and have only been using it for a couple days, so I'm sure I'll hit the limits soon and need to upgrade to the $200/mo plan. But so far the model is great and super fast.

The difference I'm noticing is that Cursor feels built for developers who actually want to see and understand the changes being made. The inline diffs are amazing. You can skim through exactly what Cursor is changing and approve or reject specific parts. It's perfect for experienced developers who know their codebase and want that visibility.

Claude Code is better when you want to fully delegate and not look at the implementation. Cursor is better when you want to stay hands on and review the changes as they happen.

I was actually using Cursor alongside Claude Code before this anyway, so it's nice to consolidate into one tool. We'll see how it holds up as I keep building, but the initial experience has been really smooth.

Landing Page Refresh

I also spent some time updating the landing page this week. The previous version was pretty minimal, so I added more substance to help people understand what Finnear actually does.

The new version includes:

• A proper feature list so visitors can quickly see what the app offers

• Screenshots showing the actual interface

• A demo video walking through the core functionality

It feels more complete now. More modern. And hopefully it does a better job of showing potential users what they're signing up for.

Building in public means sharing both the smooth decisions and the ones where you have to pivot. This was one of those pivots. Sometimes the tool you know isn't the right fit for the job, and that's okay. The important part is finding what works and shipping it.

Back to building.

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

What I'm Building

Finnear is an app for SaaS founders to see their finance metrics. Things like recurring expenses, recurring revenue, and total invested from personal bank accounts. For the past 10 years I’ve used Angular to build my personal projects. Started with Angular.js for a bit right before Google cut it for Angular2+, and that’s been my go-to framework since. For about 8 years of my coding journey I was a Node+Express guy, building endpoints to query data with mongodb. This is until I tried Supabase a couple years ago. It was game changing. For Finnear, I decided to give Convex a try.

The Tech Stack

For Finnear, I've landed on a combination that feels really solid:

Frontend: Angular I went with Angular for the web interface. Yeah, I know some people have strong opinions about Angular. To me, the structure it provides is pretty refreshing. The TypeScript-first approach, the powerful CLI, the built-in dependency injection... it all just clicks for this project. Plus, when you're building something from scratch, having those opinions baked in can actually speed things up rather than slow you down.

Backend: Convex Now this is where things get interesting. I'm using Convex for the backend, and honestly, it's been a game-changer. If you haven't checked out Convex yet, it's worth a look. It's a backend platform that handles your database, server functions, and real-time subscriptions all in one place. Its very similar to Supabase except its not a Postgres db under the hood. Its something completely custom. And you write your table schema with Typescript. The developer experience is incredibly smooth – you write TypeScript functions, and Convex handles the rest. No more wrestling with ORMs or setting up WebSocket infrastructure from scratch.

Why This Combo Works

Honestly, the skeleton for this blog was written by AI including this headline, so I’ve been trying to come up with why this combo works. The truth is when you’re starting out on a new project, the best thing to do is use tools you’re familiar with. I’m insanely familiar with Angular. I can write it in my sleep. This meant I can leverage AI tools like Claude Code and scan what it built without having to take the time to understand it. It came naturally. I tried to “vibe code” a React app that I have no experience with and it was difficult because I had no idea if the AI was using best practices.

This is my first project using Convex, so I did break my rule here. However, I heard great things about Convex, and although the first week took was mostly eaten up by understanding the flow of Convex, it has since saved me way more time than Supabase.

The Development Experience

Angular has a nice developer experience. Hot reload is clutch, but every framework has that at this point.

Convex, on the other hand, has amazing DevX. For one, you don’t run the server locally (you can if you want). Every convex project gets a dev server and a prod server automatically. When you make changes to your code, the convex cli listens to your changes and instantly updates the dev server with those changes. This is great because your frontend is always hitting a live server even during development so you never run into a problem where something works on local but not dev or prod. You also feel the slight latency when hitting the dev server. This helps me understand where I should add loading states. When server is running locally, api requests are instant so it’s hard to gauge what the experience will be like on prod.

Convex instantly updates the Types for the backend functions and data models. When I change a property name in convex, Angular instantly fails during compilation. This helps both the developer and the AI agent understand frontend also needs to change.

What's Next

I'm still early in the journey with Finnear, but I'm really happy with the foundation I've built. The stack feels modern without being bleeding-edge unstable, and I can move fast without feeling like I'm writing hacky code.

If you're considering a similar stack, I'd say go for it. The learning curve for Convex is pretty gentle. If you're already comfortable with Angular, go with it. It’s not as popular as React, but you’ll get everything you need out of it without having to learn a new framework.

I'll keep sharing updates as Finnear develops. Building in public is new for me, but it's been fun so far.

Hey there! I’m Igor, founder of Finnear. I built Finnear because I was tired of manually tracking my startup's finances. As a solo founder running my own app, I'm constantly signing up for new tools, canceling ones I don't need, and swapping services month to month based on what I need. The problem wasn't forgetting what I was subscribed to - it was the hassle of tracking it all manually. Every time something changed, I had to update my spreadsheet. It was tedious and honestly just annoying.

I wanted to know: Am I profitable yet? How much am I personally investing each month? When will this thing break even? But I didn't want to maintain a complex spreadsheet every time I added or dropped a subscription.

The Problem

Most finance tools are built for VC-backed startups obsessing over runway, or for personal finance tracking. Neither works for bootstrapped founders who need to understand one simple thing: Is my business sustainable, and if not, when will it be?

You're not worried about running out of funding in 18 months. You're worried about how much you're covering from your personal account each month and whether that number is going down or up.

What Finnear Actually Does

Finnear connects to your business bank accounts and automatically tracks three types of transactions:

Subscriptions - All those recurring SaaS tools, hosting costs, and services you use to run your business

Revenue - Money coming in from customers, whether that's monthly subscriptions or one-time sales

Capital Investment - Personal money you're putting into the business to cover the gap

Then it shows you what actually matters for a bootstrapped founder:

Monthly Sustainability Gap - How much you're covering from your pocket each month. Business revenue minus expenses equals the gap you're funding personally.

Total Personal Investment - Running total of everything you've put into the business. This is your real skin in the game.

Break-Even Projection - Based on your revenue growth trends, when might you stop needing to inject personal capital? Uses your last 3, 6, or 12 month averages to project forward.

Expense Breakdown - Which subscriptions are eating up the most money? Where can you optimize?

Revenue Trends - Is it growing? Flat? This determines everything else.

How It Works

1. Connect your business bank accounts

2. Finnear automatically categorizes transactions as subscriptions, revenue, or capital investment

3. Check your dashboard to see your sustainability metrics

4. Model changes before you make them - "If I upgrade this tool, how does it affect my break-even date?"

That's it. No manual entry, no complex accounting, just the numbers you actually care about.

Who This Is For

Solo founders and small bootstrapped teams who are:

• Covering business expenses from personal funds

• Actually want to know when they'll be profitable

• Tired of maintaining spreadsheets

• Making decisions about which subscriptions to keep or upgrade

If you're VC-funded and tracking runway, this isn't for you. Finnear is built specifically for the bootstrap journey.

What I'm Building Next

This is just the start. Coming soon:

• Scenario planning - model subscription changes before committing

• Multi-app tracking - if you run multiple products, track them separately

• Alerts when sustainability metrics change significantly

• Better forecasting based on your specific growth patterns

But I'm building based on what bootstrapped founders actually need, not just adding features for the sake of it.

Try It Out

Finnear is live on the web right now. Connect your accounts and see your real sustainability picture in minutes.

No shame about the gap. No judgment about how long it's taking. Just honest metrics about where you are and where you're headed.

Questions? Thoughts? Want to tell me I'm doing it wrong? Hit me up at igor@finnear.com