Your Data, Your Machine: How He Built the Local-First CRM That Gives Creators Control

Build to Launch Friday: Meet Finn (again!), the veteran builder who's been shipping since 1976 and still hasn't found a reason to stop

Welcome to Build to Launch Fridays, where we meet the builders turning domain expertise into AI-powered products.

Every Friday, I’m spotlighting someone from the vibe coding builders collection who’s doing exactly what I believe is the future: using AI not as just another tool, but as a true collaborator to transform curiosity, passion, and years of professional knowledge into something scalable and ownable. No VC funding, no technical co-founders, no permission required, just domain experts who decided to build.

Today, meet Finn Tropy — again. Last time we talked, he’d just launched Substack Pro Studio to overwhelming response. Now he’s back with something completely different: a local-first CRM that lets creators own their data and query it with AI.

Have you ever tried to remember who messaged you about your product two weeks ago, and completely blanked?

That embarrassingly simple problem sparked Finn’s next build. He tested every CRM he could find — Twenty, Odoo, a half-dozen others, and realized they were all designed to sell more, not build relationships.

So he built his own.

Finn has been writing software since 1976. Nearly fifty years of shipping, debugging, pivoting, and starting over. When I first featured him in September, his Substack Pro Studio had just exploded — 518+ creators using it, plus $10K+ in revenue from his Notes Scheduler alone, all built with just 4 hours a week. (You can read that full interview here.)

Now he’s built StackContacts: a desktop app that pulls all your Substack data to a local database and lets Claude query it directly. No cloud. No servers. Your data never leaves your machine.

Ever since I learnt about MCP, I went all in. Experimenting at work, building for myself, trying to understand what’s possible. When Finn mentioned he was building with MCP and Claude, I paid attention.

I know Finn. When he builds something, he gets serious. There are always unbelievable stories behind it. The time, the effort, the pivots, the late nights. So I invited him back. I wanted to dig into the spirit behind the product.

You can explore both of Finn’s products on Finn’s Vibe Coding Builders profile and see how he’s building tools that put creators in control.

Now, let’s dive in.

---

The Spark

Last time we talked, you had just launched Substack Pro Studio to overwhelming response. You analyzed 1.3M+ notes and built the tool creators couldn’t stop using. For readers who missed that, what problem did Substack Pro Studio solve?

Most creators were posting Notes blind — no feedback, no patterns, just guessing.

I analyzed over 1.3 million Notes and realized the creators who grew weren’t more talented, they were just more consistent and learned faster from what worked.

So I built Substack Pro Studio: analytics that show which Notes drive growth, scheduling that keeps you consistent without burnout, and AI templates based on actual high-performing content. It turns “throw stuff at the wall” into “okay, I see the pattern — I’ll do more of that.”

That’s why 518+ creators are using it — getting 5-10 hours back per week, 10-25% more engagement.

Quick recap for new readers. If you want the full story of how Finn built Substack Pro Studio while working just 4 hours a week, check out his first interview.

Now you’re back with StackContacts. In one sentence, what does it do and who is it for?

It’s a desktop app that pulls all your Substack data to a local database and lets you actually understand who’s reading, what they care about, and which posts are driving real results — not just vanity metrics. For creators who want to build real human relationships, not just count email opens or subscribers.

👉 Visit StackContacts | View on Vibe Coding Builders

Honestly, I’ve never used a CRM. Had no idea there were so many traps around “selling” vs. “relationships.” But real human connections over vanity counts? That I get.

You launched on Christmas Eve and got your first annual paid subscriber within 4 days. What was happening in those 4 days?

I was watching to see if the right people noticed. Those four days weren’t about promotion. They were about signal.

I shipped on Christmas Eve, fixed rough edges in real time, answered emails, and watched how people actually used the product — what resonated, where they got stuck, what questions they asked.

The first annual subscriber wasn’t responding to a launch. They were responding to clarity. They saw a tool built by someone who understood their workflow, cared about their data, and was clearly going to keep improving it.

That’s what was happening in those four days: quiet validation that the problem — and the approach — were real.

Okay, this might be the most inspirational launch I’ve ever seen. The annual subscriber wasn’t paying for a product — they were paying because Finn connected with them, helped them use it. I’m so glad it’s proving the strategy works.

And for those of you debating paywall vs. free... the distinction always felt vague to me. But when he’s offering his time? That’s totally different value. I keep thinking about “do things that don’t scale” — and Finn’s doing exactly that.

You’ve been writing software since 1976. How does it feel to still be shipping new products nearly 50 years later?

It feels like I’ve been doing this long enough to know exactly how little I actually know. Every new product is still a puzzle — different tools, different users, new headaches. But the thrill of making something that actually helps someone? That never gets old.

In 1987, when I got the first MRI brain image appear on the screen, reconstructed using Fast Fourier Transformation (FFT) from a noisy data stream, with code that I had spent six months writing and debugging, and saw the excitement of radiologists and neurosurgeons around me - it was worth all the trouble.

After nearly 50 years, I still get the same rush I did the first time I hit “run” on a program… except now I also get to laugh at all the ways it inevitably breaks in ways I should have seen coming.

Shipping products is like parenting: exhausting, unpredictable, occasionally terrifying - and impossible not to love.

Can I say I feel relieved hearing this? Because AI kind of puts us all at the same starting point again. But that doesn’t mean we should dismiss the experts in the room. They’ve accumulated experience, built up instincts, found the best ways to work. AI just amplifies all that hard work. And when someone with deep expertise wakes up to what’s possible and starts to scale? That’s what I’m watching for.

---

The Origin Story

You wrote that the spark was embarrassingly simple: you couldn’t remember who messaged you about your product two weeks ago. Was that the real origin, or had you been collecting frustrations from other creators too?

Oh yeah, that spark was embarrassingly simple — I literally couldn’t remember who messaged me about my product two weeks ago. If I can’t keep track of my inbox, I clearly can’t be trusted with the rest of the universe.

But it wasn’t just me being forgetful. Over the years I’d collected all the little creator frustrations: missed replies, scattered feedback, invisible engagement signals. I just had a brief moment of clarity that day — wait, this is actually a problem I can fix.

So yes, StackContacts started because of my own memory fail and maybe also because I like turning my weaknesses into products other people can love.

The best products come from scratching your own itch. That’s the difference between complaining and building.

Before building StackContacts, you tested Twenty CRM, Odoo CRM, and others. You wrote “the more I tested, the more they felt wrong — they were designed to sell more, not build relationships.” At what point did you decide existing tools were a dead end?

I kept testing these CRMs — Twenty, Odoo, a half a dozen others — and each time I thought, maybe this one will work. But the more I used them, the more I realized they were all designed to push sales, dashboards, and metrics that looked impressive but not actually help me connect with people.

The tipping point? When I tried to track down a simple conversation with a customer and ended up in a two-hour wrestling match with menus, fields, and workflows that made no sense. I looked at the screen and thought, if this is their “solution,” maybe I just have to build my own.

StackContacts exists because I finally admitted: the CRM tools out there were solving someone else’s problem — not mine, not creators’, not relationships. And honestly, admitting that felt like a relief.

One thing really struck me here: Finn actually tried a half dozen products before deciding to build his own. He validated that nothing fit first. I hear people ask all the time — “When do I start? Where do I start? How do I even start?” This is exactly the framework: try what exists, hit the wall, then build what’s missing.

How did you validate the idea before building? You wrote “if I’m feeling this, others must be too” — how do you know when that instinct is right vs. when you’re building for an audience of one?

That’s the million-dollar question, right?

I started with the instinct: if I’m feeling this pain, someone else probably is too. But I didn’t just trust myself — I tested it. I talked to a handful of creators, shared rough sketches and prototypes, and watched how they reacted. Did they light up, ask questions, or nod politely while thinking, “this guy’s weird”?

The moment you know your instinct is real is when multiple people, independently, say the same thing you’re thinking without you leading them. That’s when it stops being “me” and starts being a real problem.

Of course, there’s always a little risk you’re building for an audience of one — but if you combine instinct with actual signals, you tilt the odds in your favor. And honestly, a few “me-too” moments go a long way toward sanity.

This reminds me of The Mom Test — the idea that people will lie to be polite, so you have to watch for real signals, not just words. But the part that really landed for me: “multiple people, independently, say the same thing without you leading them.” That’s when you know the problem is real.

What’s the difference between “I want this to exist” and “I should be the one to build it”?

I know I should build something when I see a gap, feel the pain personally, and realize no one else is likely to solve it the way I can.

Basically: wanting is easy. Building is scary and oddly addictive.

Funny thing — I would never have agreed with this before AI. Building felt too scary. But ever since I started, I’ve become more and more inclined to just... make things. I’ve built at least a dozen personalized tools I never shared — too small, too specific, never found the right moment. And I’m seeing this everywhere now among people who use AI daily. Building is becoming a habit, not an event.

---

Technical Architecture

You’ve switched tech stacks multiple times across your products. For StackContacts you’re using Go, DuckDB, Fyne GUI, Chrome extensions, Python MCP servers. How many major technical pivots have you made?

How many major pivots? Enough to make me question my life choices - at least five times over.

StackContacts has been a full-on tech playground: Initially a Python CLI app, then Go for the backend, SQLite for analytics database, Fyne for the GUI, Chrome extensions and Python MCP servers for quirky edge cases - then pivots to Tauri and PyApp frameworks to finally ship a signed and notarized macOS app, and now a Windows application using the same architecture. The Python DLT library for the data pipeline and DuckDB for the analytics database added another layer of “oh no, what did I just unleash?”

By the fifth time building from scratch, you start to develop a weird combination of pride and PTSD. Every pivot teaches you something: what to over-engineer, what to hack, and what to completely accept will explode later.

It’s exhausting. It’s messy. And somehow, I still love it. Because at the end, all those pivots add up to a product that actually works the way creators need it to.

Haha, good to know I’m not the only one questioning my life choices. But honestly? Finn just loves building — even without reward. What strikes me is how much time he’s willing to invest just to find the most satisfying stack. Is he doing the right thing according to textbooks? I doubt it. Is he doing the right thing for himself? Definitely.

What’s the theory behind why you keep changing stacks? Is it about the problem, or about what you’re learning?

It’s both… but mostly the problem comes first.

I change stacks because each combination surfaces a new set of constraints: scale, speed, reliability, ease-of-use, or just “how the heck do I make this cross-platform (macOS, Windows, Linux) without losing my mind?” The tools follow the problem, not the other way around.

The learning is a bonus - every pivot teaches me better patterns, smarter architectures, and what I should never do again.

So yeah, I’m chasing solutions, but I’m also hoarding lessons like some weird, caffeine-fueled software archaeologist.

“Caffeine-fueled software archaeologist.” I’m using that.

Each stack change is a time sink. How much personal time did these pivots consume?

I’ve lost more weekends than I can count — which, at this point in my “retirement,” is starting to feel like a full-time hobby.

Each stack change was basically a small personal apocalypse: learning Go well enough to trust it for production, wrestling with Fyne GUI quirks, figuring out Tauri and PyApp packaging, and making a signed, notarized macOS app. Then adding Windows 11 build and integration into the mix. Throw in DLT pipelines and the Python MCP server… and you’re looking at hundreds of hours over months — nights, weekends, and a few “wait, is it 2026 already?” moments.

Sleep got sacrificed. Other projects got postponed. But here’s the thing: every pivot was like a forced masterclass. Painful? Absolutely. Worth it? Totally.

Sleep gets pushed later and later, other projects get postponed — I totally feel that. Not just building products, but writing with AI, content creation, everything. You just can’t stop. And “forced masterclass” is such the right term for it. It’s like learning dramatically multiplied. I’m starting to think this might be the new way of learning for everyone.

The first time you synced your Substack data, it took 42 minutes just to pull 1,000 subscribers. Now it takes under 2 minutes. What was slowing it down, and how did you fix it?

The first sync was painfully slow — 42 minutes for 1,000 subscribers.

Turns out the culprit wasn’t my code, it was me misreading the DLT library. DLT is actually caching everything it extracts, so once the “heavy lifting” and thousands of API calls was done, sync to the database was quick. Once I realized that, I focused on optimizing the transformation and load steps — and DuckDB, built for exactly this kind of workload, chewed through it in seconds. I did testing earlier with SQLite3 database using the Go / Fyne version and found out that DuckDB is the right tool for storing analytical, transformed and flattened database tables.

So now that task that used to feel like watching paint dry is done in under 2 minutes. Funny how a tiny insight — and the right database — can turn 42 minutes of despair into 120 seconds of smug satisfaction.

I’d never heard of DuckDB before this — but now I’m curious. A personal analytics database I can actually use? Also interesting that modern libraries handle caching so well. It’s really the algorithm that makes the difference now. But wait — thousands of API calls and no rate limits? How did that even work?

Why DuckDB specifically? For readers who don’t know, it’s an embedded database that runs as a single file on your Mac.

I tested SQLite first — tiny, ubiquitous, zero setup, perfect for small CRUD workloads. But with hundreds of tables and 500+ MB of data, multi-join queries, aggregations and transformations got sluggish, and single-threaded queries made me miss my weekends even more.

A locally hosted Postgres would have been powerful, but it’s overkill for a single-user desktop app: extra local server setup, config headaches, and maintenance I didn’t need just to crunch local analytics.

DuckDB, on the other hand, is basically a local analytics powerhouse. Columnar storage, vectorized multi-threaded execution, and native support for JSON logical field type make complex queries fly — all in a single file, zero server, zero headaches.

In short: SQLite is cute and convenient; Postgres is overkill; DuckDB is the muscle behind StackContacts’ syncs and analytics.

Really great to learn these nuances. I’d probably default to Postgres — but like Finn said, it requires setup. Actually, I had a client who specifically refused to install local Postgres because of the overhead. Now I get why that matters.

---

The MCP Architecture

I see MCP as the gold mine for AI-powered tools in 2026 and beyond. Your app pulls data from Substack, stores it locally, then lets Claude query it. Walk me through what happens when someone asks Claude “what pages did my most engaged readers visit in the past 3 days?”

Okay, so — Claude gets that question and makes a tool call to the Python MCP server to get the database schema. I’m using an open-source DuckDB MCP library, which honestly saved me weeks because the database connection part was already figured out.

Claude converts the English into SQL using tables and relationships in the schema. Sometimes it’s beautiful SQL, sometimes it’s... creative. The MCP server shoots that query to DuckDB, which runs locally on your Mac. DuckDB is fast — like, stupidly fast — because it’s designed for analytics. Multi-threaded, columnar storage, all that good stuff.

Results come back — but here’s the catch. Claude context window can’t handle a million rows, so there’s a limit around 500 rows. Which is fine for most questions, but when someone asks for “all my 100K subscribers,” we have to teach them to query DuckDB directly instead.

Then Claude takes those numbers and translates them back into English.

The whole thing takes maybe 2-3 seconds? It looks seamless. Behind the scenes I’ve been debugging SQL generation bugs for the past two weeks, but... yeah. It works now. Mostly.

This is the future. You ask a question in English, Claude writes SQL, queries your local database, and answers in English. And it takes 2-3 seconds. Crazy that two years ago this was science fiction.

You’re using an open-source MCP server to let Claude talk directly to your database. How much of this architecture did you design yourself vs. discover from existing tools?

It’s a mix of both.

The open-source MCP server gave me the bridge, the plumbing to connect Claude to a database. That part I didn’t reinvent — I stood on someone else’s shoulders there.

Where I added the sweat and tears was in adapting it for StackContacts: making it talk to DuckDB efficiently and building it as self-installing MCP server as part of the MacOS and Windows app.

So yes, I didn’t invent the wheel — but I polished it, widened it, and made sure it could haul a small mountain of Substack analytics across my desktop.

Good reminder: there’s absolutely no need to recreate the wheel every time. Reusing what already exists is totally fine.

Were there dead ends with MCP that almost derailed the project?

So many.

The Tauri→Python bridge broke for like two weeks in December. Messages just wouldn’t get through. Turned out to be an async/await issue that took me forever to debug.

Then Claude kept writing malformed SQL. It would hallucinate table names that didn’t exist, or join on the wrong columns. I had to add validation and error handling for basically everything.

Oh, and DuckDB has this quirk where if you query it while a sync write is happening, the whole thing locks up. Had to add logic for concurrent access.

Each of these felt like project-killers when they happened. But you just fix them one at a time and eventually it works. Mostly.

Thankfully I didn’t have to go through all this. I used Installer Proxy as my MCP, so no Python bridge headaches. And I kept a simplified schema locally, made Claude always reference it — no hallucinating table names. But still, I can already imagine how painful those issues must be. Finn just... fixed them one at a time.

When users ask Claude questions, it can only handle about 500 rows of data at once. So you teach people to bypass it by querying the database directly. Was that limitation a surprise?

Expected. Frustrating, but expected.

I knew AI context windows max out somewhere around there. I tested it early — asked Claude to process 2,000 subscriber rows and watched it just... choke. So yeah, 500 is the safe zone.

But instead of hiding that, I just documented it. Like, “hey, if you want all your data, here’s how to query DuckDB yourself.” Install the CLI tool, run SQL directly, export to CSV. Takes five minutes to teach. And Claude will give the query, so you don’t need to be an expert. Just copy / paste like you do with prompts.

Some people love it because they get full control. Some people are like “wait, I have to learn SQL?” and I get it, that’s a barrier. I may need to add a simple UI for this.

I don’t know if it’s the right call long-term, but for now it works. The AI is good for exploratory questions — “show me patterns” — and direct database access is for when you need everything. Or export to some other tools.

Ha — thank you for disclosing this. “Wait, I have to learn SQL?” is exactly the kind of question I get at work when I ask people to just work around a problem. But back to context window: I encounter it differently. Claude likes to resolve things bit by bit, which means it keeps retrieving SQL queries — and that alone eats up the context window. I made my MCP slightly smarter to bypass some of it, but this is still a problem Claude needs to solve. I know how easy it could be for them to address from their end. For us end users, it’s hard.

Your target user is someone with Claude Desktop or Cursor IDE. That’s a narrower market than “all Substack creators.” Is that a strategic constraint, or do you plan to expand?

Yeah, it’s narrow. Maybe too narrow? I go back and forth on this.

Right now I’m targeting people who already use Claude Desktop — maybe a few thousand Substack creators, max. They get the MCP thing immediately. They understand AI workflows.

But I’m not naive. Most Substack creators don’t even know what MCP is. They just want insights without installing command-line tools.

So do I expand? Probably. I’ve been thinking about a web version, or a simpler standalone app that doesn’t need Claude at all. But that’s months away, and honestly I wanted to ship something working first rather than wait for the “perfect” broad-market solution.

For now, it’s early adopters who already live in this world. We’ll see if that was smart or if I just built for too small an audience.

This all makes sense to me. I have a bold bet: Claude Desktop is going to become universally adopted, and that’ll create a huge user base that justifies building MCPs like this. For those who don’t know Max — he’s one of the best AI builders I’ve encountered. Zero coding background, but he’s already built and shipped a handful of productivity tools and newsletters. That’s the future Finn’s building for.

Your newsletter teaches readers how to install a command-line database tool and write SQL queries. Most product builders would hide all that behind a pretty interface. Why show the complexity?

Because hiding complexity doesn’t make it go away — it just makes users powerless.

StackContacts isn’t about looking pretty; it’s about giving creators agency over their data. Showing them how to run SQL queries and interact with a local database lets them explore, experiment, and answer questions that no pre-built interface or dashboard could predict.

Plus, if I did hide it, I’d just be creating another black box — and I’ve spent decades hating black boxes. This way, users can see the gears turning, make adjustments, and actually own their data and analytics.

“Hiding complexity doesn’t make it go away — it just makes users powerless.” This is the opposite of how most products think. And I kind of love it.

What do you think MCP will look like in 2 years? Are we early, or is this already mainstream?

Super early. Like, I’m pretty sure 99% of people have no idea what MCP even is.

In two years? I think we’ll see way more integrations — databases, APIs, local files, cloud services. Right now it’s kind of a mess figuring out how to wire everything together. The documentation is sparse. You’re mostly copying examples from GitHub and hoping they work.

But Anthropic is clearly investing in it. So are other AI companies. I think it’ll become the standard way AI talks to external data — whether that’s your local files or someone’s API.

Or maybe I’m completely wrong and something else takes over. That’s the risk building on bleeding-edge stuff. But right now it’s the best option I’ve found for “let AI query my local database without sending everything to the cloud.”

I love this perspective. I hope he’s right because I’m betting on the same thing. MCP is going to break the current website-based SaaS model — it’s going to connect all the intelligence for people. I echo the problems though: right now, adding authentication for website-based MCP isn’t even doable. I have to build custom MCPs that only work on desktop. But we’re still early. Lots of room to figure it out.

---

Discovery & Insights

The killer feature seems to be revenue attribution — tracing “post read → link clicked → purchase made.” What is the number one advice for creators?

Track the path, not just the sale.

I spent months looking at revenue and thinking “great, someone bought!” but having zero idea why. Like, was it the Note I posted Tuesday? The article from last week? Something else entirely?

Then I started actually looking at the sequences. This one person read five posts over two weeks, clicked three different links, replied to a Note, then bought. That’s a story. That’s a pattern you can repeat.

Most creators just see “32 sales this month” and call it success. But which 32 people? What did they all do before buying? If you can’t answer that, you’re basically gambling.

I’m still figuring this out myself, by the way. StackContacts gives me the data but I’m learning what to do with it as I go.

I love hearing stories like this. Tracking the path is such an underrated skill, and Finn is one of the few people I’ve seen actually do it this systematically.

Matching readers across platforms sounds simple until you realize people use different emails for Substack vs. Gumroad. How messy is that in practice?

Oh man, it’s a nightmare.

Like, “john.smith@gmail.com“ on Substack and “johnsmith@gmail.com“ on Gumroad — same person? Maybe. But then you’ve got “j.smith@gmail.com“ or “jsmith@yahoo.com“ and now you’re guessing.

I’m doing fuzzy matching on email domains, comparing names when they’re available, looking at purchase timing — if someone bought within 5 minutes of clicking a link from a post, that’s a strong signal. But it’s not perfect.

Last week I had a case where someone used three different emails across Substack, Kit, and Gumroad. Same person, confirmed by name and payment method, and a support request, but completely different emails. How do you automate that?

Right now I’m getting maybe 70-80% accuracy on automatic matches. The rest need manual review or you just accept you can’t connect everything. It bothers me, but I don’t have a better solution yet. I’m looking into UTM link parameters and timestamps, as that may yield better matching.

Holy moly. I don’t even want to think about that. Huge respect for Finn being willing to even tackle this problem.

You discovered link clicks are 4.5x more predictive of purchases than email opens. Did that change how you write your own posts?

Yeah, completely.

I used to obsess over headlines, test different send times, all that. But my email opens barely correlate with sales. Clicks though? Huge difference.

Now when I write I’m thinking “where’s the natural place to add a link?” Not in a pushy way, but like — if I mention the tool, link to it. If I reference a tutorial, link it. If I’m talking about a feature, link to where they can try it.

I’m also tracking which links get clicked. Like, in my last post about audience segmentation, 23 people clicked through to the tutorial but only 4 clicked the pricing page. That tells me something about where they are in the journey.

Still figuring out how to use this info without becoming weird and salesy about it.

I’ve been experiencing similar things — a few of my referrals and affiliations on Substack came through this way. So encouraging to see. And honestly, so fascinating to learn how it actually happens.

You ran your own newsletter through the tool and discovered you’d “ghosted 100% of your new subscribers.” How did that come up?

Oh, that was a humbling one.

I ran my own newsletter data through StackContacts and realized I hadn’t followed up with any of my new subscribers — zero, nada, ghosted 100%. I’d been so focused on creating tools and analyzing content that I completely ignored the simplest relationship-building step: saying hello.

It came up because the tool highlights real engagement gaps, not vanity metrics. Seeing it in black-and-white was embarrassing — but also the perfect kick in the pants to actually start engaging my audience.

Okay, this is me. That’s a wake-up call. I should get started drafting contacts now.

What’s the most surprising insight someone else discovered using StackContacts?

Someone — Phil Powis ❤️⚡️, actually — posted this morning that his audience splits into two distinct groups: business people and personal growth people. Almost zero overlap. He had no idea.

That hit me because 18 months ago I tried doing the exact same analysis on my Medium followers. Spent three days scraping bios with Python, trying embedding vectors, gave up and used keyword matching in Google Sheets. Found some vague patterns but nothing actionable.

StackContacts is basically my third attempt at solving that problem. Except now Phil just asked Claude “segment my audience by interest” and got an answer in 30 seconds.

I’m not gonna lie, seeing someone discover in minutes what took me days feels both validating and slightly annoying. Like, where was this tool when I needed it?

“Validating and slightly annoying.” Building a tool that solves your past self’s problem is a weird feeling. But that’s exactly why the tool works, Finn knows the pain because he lived it.

---

The Human Side

You went from testing existing CRMs, to building prototypes, to optimizing ETL, to learning Fyne GUI, to creating Chrome extensions — all while maintaining two newsletters. How much total time have you invested in StackContacts?

Enough to make “weekends” feel like a distant memory.

From testing existing CRMs, to building prototypes, optimizing ETL, learning Go language and Fyne GUI, building Chrome extensions, and running two newsletters on the side… I’d estimate well over a thousand hours spread across 8 months. Nights, weekends, and a few “wait, is it still 2025?” moments got sacrificed along the way.

It’s exhausting, sure — but it’s also the kind of work that turns half-baked ideas into something creators can actually use. And somehow, after all that, I still look forward to the next pivot.

Honestly? I feel so much less alone hearing this. Knowing others are spending their nights and weekends the same way, it gives me strength to keep going. We’re all in this together.

Your first onboarding guide had 27 steps users had to follow manually. You whittled it down to 14, then built a proper Mac installer, then added a setup wizard. Was there a point where you questioned whether the polish was worth it?

Oh, absolutely — many times.

The first guide had 27 steps and I thought, this is going to be terrible… but I’m too stubborn to change it yet. Cutting it down to 14 felt like progress, but building a proper Mac installer and a setup wizard each took way more time than any user would ever save. There were nights where I seriously questioned whether I’d lost my mind polishing something so small.

But the point isn’t just saving time — it’s removing friction so creators can focus on insights instead of setup pain. Now, the onboarding is fairly smooth, the Mac installer works, the users can get it running in less than 15 minutes. I got a new Windows 11 Pro machine on Jan 2nd, learned how to build and package Windows apps, and yesterday the first beta tester reported success with the latest StackContacts for Windows installer.

LOL, Finn, you’re going crazy. I have the same setup: Windows 11 on a virtual machine to package Windows apps, plus packaging Mac MCP installers. But that was for work for the time being. And I totally echo this: the friction to install and how simple it is to use matters more than the tech stack, the complexity, even the skill sets to some extent.

You wrote “nothing ships cleanly” and showed the messy parts — false starts, failures. What was the lowest point during this build, the moment you almost walked away?

The lowest point? Definitely the Go/Fyne phase.

It was around September 24th, 8:37 PM on a Wednesday (per git logs). I had a spreadsheet open with 500+ SQL table transformations I’d have to write, validate and maintain manually. I’d been staring at it for an hour, doing the math: 500 tables × 10 minutes each = 83 hours of boring, error-prone work. And that’s before testing.

I remember closing my laptop, walking outside, and just standing in the driveway in the dark. My wife came out and asked if I was okay.

I said, “I think I designed this wrong.”
She said, “So redesign it.”
I said, “That means starting over. Again.”
She just looked at me and said, “You were going to do that anyway.”

She was right. I went back inside, Googled “Python ETL libraries,” found DLT, and realized I could automate 90% of what I thought I’d have to hand-code.

Sometimes the lowest point is just the moment before you find the right tool.

Oh, this is so sweet. I love your wife. The lowest moment really is the pivoting moment, I completely agree. I experienced something similar just this November, with family around. And the best part? I felt so relieved when everything broke, because now we can rebuild it. Absolutely love how chill and wise she is.

You’ve been building for nearly 50 years. Does it get easier to push through the hard parts?

You’d think after 50 years it would get easier — spoiler: it doesn’t.

Every build still has that what did I get myself into? feeling. The tools change, the bugs change, the users change — but the panic, the late-night “is this even possible?” moments, they’re all still there.

What does change is perspective. I know now that the hard parts are temporary, the messy bits are normal, and the thrill of turning chaos into something people can actually use is worth every headache.

I keep asking Finn about building for 50 years because it carries so many dimensions — technical experience, time and devotion, emotions, self-esteem, identity. All of it matters, especially with AI impacting everything. If you have decades of expertise, I’m sure you’ll echo with this. One thing I’ve learned from asking these questions: getting your expertise pushed over and over again helps build who you are. It builds up a spirit that stays.

What did your partner or family think about the time you were putting into this?

They’ve been amazingly supportive — probably because after spending 40+ years together, my wife knows how these obsessions go. She’s got a PhD in computer science, so you can imagine some of our discussions… a mix of “are you serious?” and “well, at least it’ll work eventually.”

My daughter recently asked, “I thought you were retired — why do you have meetings?” That one got a laugh (and a little eye-roll).

They’ve seen enough of these deep dives to know I won’t change. So yes, it takes time, yes it’s obsessive… and yes, I’m lucky they stick around while I do it anyway.

This is super sweet. The support from family really keeps you going. And I echo your daughter’s question, I’ve asked it in my heart a million times: “I thought you were retired. I thought you were going to be chill. What’s going on with you? What’s the plan now?”

---

Business & Philosophy

You launched a separate StackContacts newsletter alongside your main Finntropy newsletter. How did that launch work?

Awkward launch. I sent one email to Finn’sights subscribers on Jan 1st saying “hey, I made this other thing” and got maybe 15 signups. Then crickets for a week.

The weird part is the first paid subscribers weren’t from Finn’sights at all. They found StackContacts through the product launch preparation, got the Beta version of the app, then subscribed to the newsletter to learn how to actually use it and support me building more. Which makes sense, but I didn’t plan it that way.

Now I’m trying to figure out what the StackContacts newsletter even is. Tutorial content? AI prompts? Behind-the-scenes building notes? I’ve published maybe 6 posts so far and they’re all over the place tonally.

It’s growing, but slowly. 42 free subscribers, 1 paid. Not terrible for three weeks, but also not exactly crushing it.

I really appreciate you sharing this. Honestly, before reading this answer, I thought your content was strategically placed and super focused. Now I’m learning it’s all over the place? Interesting. What I see might not be what it actually is, and what you think might not be either.

Now you’re running two newsletters plus building products. How do you think about whether product and newsletter should be coupled vs. operating separately?

I honestly don’t know if I’m doing this right.

At first I tried mixing everything — Finn’sights posts about StackContacts, StackContacts posts about Finn’sights philosophy. It felt messy. People subscribed to Finn’sights for one reason and suddenly I’m pitching them software?

So I split them in late December. Finn’sights is still my “whatever I’m thinking about” space — AI, writing, business experiments. StackContacts newsletter is supposed to be focused: tutorials, AI prompts, audience analysis tips.

But now I’m managing two separate audiences, two content calendars, and honestly some weeks I forget to post to one or the other. Last week I almost published the same post to both by accident.

Maybe later they merge back together. Maybe one dies and the other survives. Right now I’m just trying to keep both alive while shipping product updates.

The reason I ask is because it really can get difficult. Just one newsletter is already eating up all my time. I can’t even imagine how busy you must be, in your “retired” life.

$19+ one-time for the app, plus a paid newsletter tier with AI prompts and office hours. How do you think about product revenue vs. newsletter revenue?

I think about it in terms of value streams, not just dollars.

The app is a one-time product — it delivers a concrete tool that solves a real problem. The paid newsletter tier is about ongoing guidance, office hours, AI prompts library, and community support — something that grows in value the longer someone engages.

Revenue-wise, the app gives a quick win; the newsletter builds recurring relationships and insight. Together, they reinforce each other: the app shows what’s possible, the newsletter helps people use it better. And honestly, I like having a mix so I’m not relying on one thing to keep the lights on.

You know what? $19 for this product is really not expensive at all for the value delivered. Finn always surprises me — how he builds, how he sells, how he manages to generate great revenue even at such a low price.

What’s the AI prompt people copy-paste into Claude most often?

Hands down, it’s the one that asks Claude to analyze my audience and help to improve conversion to paid — basically “tell me what’s working, what’s flopping, and how to fix it.”

People love it because it turns audience behavior data into actionable ideas in plain English. Copy-paste, run, and suddenly you’ve got a mini analyst on your desk.

Audience analysis + conversion advice. That’s the question every creator secretly wants answered.

“Your data never leaves your Mac” is a strong stance when everyone else runs on cloud. Was that philosophical, technical necessity, or both?

Mostly practical, with a side of paranoid.

I hate depending on servers. Hate paying for hosting. Hate worrying about security breaches or GDPR compliance or “oh no, AWS is down and my whole product is broken.”

Plus, DuckDB is really fast locally. Like, queries that would take seconds on a cloud database take milliseconds on your laptop. No network latency. No waiting for API calls.

The philosophical part is real too — I think creators should own their data. Not have it sitting in some company’s rented database where it could get sold or leaked or subpoenaed or whatever.

But honestly? The main reason is I didn’t want to build and maintain yet another backend server. Desktop apps are simpler. One download, it just works. No server costs, no scaling issues. That’s worth the tradeoff of being Mac/Windows only for now.

I learned from Finn in the last interview how much he values less server overhead. This proves it again. And somehow, it’s making me want to build more offline tools myself.

What did this build teach you about your own taste as a builder?

I really don’t care about making things pretty. At all.

Like, the StackContacts interface is functional but kind of ugly. Basic Tauri app with some tables and buttons. No animations, no fancy design. And I’m okay with that?

What I do care about is speed and accuracy. If the AI query takes 15 seconds or session times out, that must be fixed. If a query returns the wrong data, I’ll debug it for hours.

I also realized I’d rather show people the raw tools — SQL, command line, database files — than build a simplified interface that hides everything. Which limits my market but feels more honest.

Not sure if that’s “taste” or just stubbornness. Probably both.

I’ve received some feedback that I need to focus on polishing the UI. I think that can come later, because this tool is not designed for general public.

Anyways, the Claude or Cursor app is the main user interface. I don’t want to reinvent the wheel.

I relate to this. I’m doing the same, get the app working first, then focus on polish later.

What question would you love someone to ask you about this build that almost never comes up?

I’d love someone to ask, “What did you learn about your own users while building this?”

Almost everyone asks about features, tech, or workflow hacks — which is fine — but the real revelations came from seeing how creators actually behave, what gaps exist, and how messy real-world data is. That’s where the magic lives: in understanding people, not just building tools.

Plus, it lets me brag a little about all the embarrassing mistakes that turned into insights — like ghosting my own subscribers or discovering tiny audience segments I never expected.

Ha — I’d be happy to ask those.

Beyond the product stack, what’s your personal productivity stack — the tools, habits, or life hacks that actually enable you to build while juggling everything else?

I use Obsidian for notes, Git for version control, Cursor for coding, Claude or ChatGPT for debugging when I’m stuck. That’s basically it.

Habits? I work in the morning, usually 8am-noon. After that my brain stops working and I answer emails or write newsletter posts. Afternoon I have long walks with my dog. Evenings are for family, and reading. Sometimes I wake up in the middle of the night, write an idea using Obsidian on my phone, and go back to sleep.

I don’t do long marathon coding sessions anymore. Did that in my 30s and 40s and burned out repeatedly. Now it’s 3-4 hours of focused work, then I stop. Took me decades to figure out that’s sustainable.

I also keep running text files called “stackcontacts-todo.md”, “substackprostudio_todo.md” etc. with everything I need to fix or build. Super low-tech but it works. When I sit down each morning I just open one of those files and pick something.

No secret productivity system. Just showing up consistently and not trying to do eight things at once.

How does this tool stack look to you? To me, it’s one of the simpler stacks I’ve seen for someone this productive. And it reinforces the idea that tools are just amplifiers — how much they amplify really depends on you and how you use them.

---

Connect & Explore

Finn’s Products:

• 🚀 StackContacts — Local-first CRM that lets Claude query your Substack data

• 🚀 Substack Pro Studio — Analytics, scheduling, and AI templates for Substack creators

• 🚀 Substack Scheduled Notes — The original Notes scheduler (500+ users)

• 👤 Finn’s Vibe Coding Builders Profile — See all his projects and journey

Finn’s Newsletters:

• 📧 Finn’sights — Weekly insights on writing, building, and learning from the best

• 📧 StackContacts Newsletter — Tutorials, AI prompts, and audience analysis tips

---

Final Thoughts

When I started Vibe Coding Builders, I wanted to make this building journey less lonely — for me, and for everyone who joins. We might be at different stages, but our struggles are identical. Building is exciting. The struggle is frustrating. The tech stack matters, but it’s only part of the story. Finn’s interview reminded me why I do this: the real lessons live in the emotions, the pivots, the moments when you almost quit but didn’t.

Finn delivered. The wife saying “you were going to do that anyway.” The pride and PTSD of five major stack changes. The 42-minute sync that became 2 minutes after one debugging insight. This is what building actually looks like when you zoom in.

What strikes me most isn’t the tech or the 50 years of experience. It’s that Finn keeps showing up. Every dead end turns into a new path. He didn’t wait for MCP to become mainstream. He built on it while Claude was still hallucinating table names.

I’m so glad he joined this interview. I’m sure you’ll feel as connected as I do.

If Finn’s combination of experience and experimentation resonates with you, connect with him. He’s exactly the kind of builder worth knowing.

If you’re turning your expertise into products, building with AI, or helping others do the same, you belong here. Join the vibe coding builders community and get featured on Build to Launch Friday. Curious why it all started? Here’s the full story behind Vibe Coding Builders.

Your turn:

What data about your audience are you ignoring because you don’t have a way to see it?

What tool would you build if you knew the complexity wouldn’t scare people away?

Finn went from “I can’t remember who messaged me” to shipping a local-first CRM with AI integration — in his retirement. What will your builder story be?

— Jenny