Ecom CFO Notebook – AI CFO bot, week 2: I built the first workflow. Here’s what I’d change

Thank you guys again for pointing out the issues in last week’s edition and being patient with my correction email.

I was reminded of how important checklists are – even when you’ve done something dozens of times.

Last week was about how I’d approach building an AI CFO bot.

The core idea: a CFO is just a collection of workflows.

Each workflow has the same anatomy — a handful of steps, data sources, a cadence, people, and a context layer. Instead of trying to build a monolith bot, you pick one workflow, build it well, and then expand.

Last week was the theory.

This week I’m going to show you what it actually looks like to build one of these workflows — through the lens of something I built for myself, what it’s allowing me to see, and how I’d approach it if I were doing the same thing for a client.

I’m not a developer. I can’t read code. But I can scope a problem, define what’s in and what’s out, and apply the same incremental discipline I use when building financial infrastructure for clients.

That turned out to be the part that actually mattered.

If you want to watch instead of read:

Problem: I couldn’t easily analyze how my own content and marketing was performing.

To figure it out, I was logging into Google Search Console, Google Ads, LinkedIn analytics, then X analytics, then Beehiiv.

At least six platforms every single time. Pulling csvs and uploading to Claude manually. No way to easily view the data week-to-week.

The output from Claude is typically useful, but it was a completely manual, tedious process.

And the next week I’d do it all again. I’d try to do it in the same Claude project but sometimes I’d be too busy.

I didn’t just want the data in one place. I wanted to give Claude enough context to actually diagnose problems, not just crunch siloed numbers.

Everything off the shelf for this is either nonexistent, not customizable, or really expensive.

This is the exact same problem our clients have with analyzing data for financial decisions. Data sitting in six different platforms, someone (us) manually pulling it together, no continuity week to week. The workflow is the same whether it’s marketing data or financial data — it’s just a different dataset.

This is where I’ve been off the rails in the past. Before you scope what’s in, get explicit about what’s out.

I’m not building execution into the workflow. This thing does not post on my behalf, doesn’t touch bidding strategies in Google Ads, doesn’t create campaigns, doesn’t build ad creative. In the future, maybe. Not now.

I’m also not pulling in data that’s inherently ambiguous. Referral sources, the random business development chats sitting in my email, informal partner conversations. That context exists, but it’s messy and manual to capture, and it isn’t worth the effort for v1.

What’s left is my minimum viable success.

Getting clear on that one thing is what keeps a project from sprawling into something I’d never finish.

This is the same scoping exercise I do with clients. When a $30M brand comes to me and says “we want better reporting,” the first conversation isn’t about dashboards or tools.

It’s about what decisions you’re trying to make, what data you actually need, and what you’re explicitly not solving right now. Most projects that stall never had that conversation.

Last week I said every workflow has the same anatomy: data sources, cadence, stakeholders, context, and steps.

So I literally filled it out on my own use case:

Few data sources. Defined cadence. One stakeholder. Clear outcome.

Last week I said your first workflow should have few data sources, a consistent cadence, as few people in the loop as possible, and a defined outcome you can prove as right or wrong. This checks every box. If yours doesn’t look this clean, pick a simpler one.

We’ll skip all the technical play-by-play. The short version: I used Claude Code as my builder, Supabase as the database, and built a very simple dashboard that runs locally.

You need somewhere to store the data, something to view it, and a tool to build it. That’s it. No hosting provider, no design system, no authentication. If you find yourself researching hosting providers before you have data in a database, you’ve already gone off the rails.

The process was: brief Claude on what I’m building and why, let it generate a first pass, then iterate.

As a non-technical person, the iteration part is the hardest.

You’re pasting error messages back and forth. You don’t understand the errors — but you don’t need to. You just need to relay them accurately. Claude debugs its own code through your eyes.

It’s not glamorous. There were moments I almost walked away from the whole thing.

But it works, and the reason it works is the scoping. Because I’d defined such a narrow problem — one dataset, one viewer, one output — the debugging loop stayed manageable. Every time I’ve tried to build something ambitious, the debugging loop is what killed it.

All of these builds follow the same emotional arc. Excitement, then a first working version that’s genuinely ugly, then “okay, I don’t hate it,” then iteration, then something actually useful.

Most people quit at ugly. Don’t quit at ugly.

I used to think the move was to build bigger. Think two or three versions ahead and build for where this is going, not for where it is.

For a non-technical person, I now realize the dangers in that line of thinking.

A few reasons. Your time is limited. Every extra layer of ambition multiplies the time you spend stuck debugging. And when you can’t read the error messages yourself, ambitious scope is the thing most likely to make you quit. I’ve run into this myself.

So instead, be incremental.

Solve one problem, ship it, use it, then decide what’s next. Don’t architect three versions ahead when you haven’t shipped version one.

Small wins keep the momentum going, and momentum is what actually gets these projects finished.

This is the same thing I tell clients about their financial infrastructure.

Fix the books before you forecast. Forecast before you model. Model before you build a full planning tool. One layer at a time. I just had to learn that it applies to building software too.

This worked because it’s a small, structured dataset with exactly one stakeholder and low stakes. Be honest with yourself about whether your use case looks like this.

The data refresh is only as good as the API connections behind it. Some platforms make that easy. Others make it painful, or close to impossible. Claude can only interpret what you give it — garbage in, garbage out still applies.

The dashboard works great for me, but the moment I needed to share it with a team, the architecture would have to change significantly. Authentication, hosted views, who’s allowed to see what. And the debugging loop, as a non-technical person, is real. The incremental approach is the only reason I didn’t quit.

The people who ship useful AI workflows (AI CFO bot or otherwise) pick one problem, define what they’re NOT building, choose the simplest architecture that solves it, iterate through the rough patches, and finish.

The people who try to build the end state (or replace the human entirely), get overwhelmed, and give up (or never really start in the first place).

The same pattern plays out in finance. The brands with the best financial infrastructure didn’t build it all at once.

They got the books right, then added reporting, then added forecasting, then added planning. The ones who tried to jump straight to a planning tool with bad books underneath it wasted six months and started over.

If you’re sitting on an AI build idea right now — whether it’s for marketing, finance, operations, or anything else — run it through the same two filters I used:

If you or your team can’t answer both in just a couple sentences, it’s already failed.

Depending on how much you guys like this week’s edition, next week, I’m planning on taking the same approach to an ecom-specific client problem.

A $100M brand with five inventory locations, three sales channels, several stakeholders who all need different things, and a demand planning model living in an Excel file that I built three years ago — Frankensteined to its breaking point.

They already tried throwing that spreadsheet into Claude and asking it questions, but it didn’t work. That’s the stress test — more data sources, more stakeholders, higher stakes. We’ll see what breaks.

-Sam

Talk to me

My inbox is open and I love hearing from you – respond to this email with your questions, feedback, things I screwed up, or just because.

Looking for more? Some of our most popular posts:

Did someone forward this to you? If you like it, you can subscribe here