A build-vs-buy call, and the pricing bug the ledger never saw

TLDR: I taught Claude how to cycle count this week and it’s still mad at me.

The weekly journal of one fractional CIO and his team of unruly AI agents. Week ending July 4th.

The leadership table

This week I ran the client’s weekly managers meeting, the IT dept meeting where we align on projects internally and with our contractors, and the daily ops standups; sat the weekly sales meeting; and worked a retail payout policy question with the owners. Two vendor meetings on top of that: a working session holding our integration vendor to the data feed the storefront migration below depends on, and a marketing strategy session with the flagship brand we distribute, planning how their brand and the client’s storefront sell together next quarter.

None of it can be delegated to an agent. Every hour my agent team spends building traces back to a decision made on one of those calls.

The store count

Version two of a barcode store-inventory app shipped inside the client’s ERP this week. Staff walk the store scanning items; the app takes a live count, compares it against what the system says is on hand, and rolls the variance into a leakage panel: the shrinkage, in dollars, by item. The same walk sets each item’s preferred stock level, and the updates commit in the background so the person counting never waits on a spinner.

I set the requirements from the store’s feedback on version one; my agent team built it. QA flagged five defects on the first pass; the second pass came back clean. The number I don’t have yet: the shrinkage total. The first full store walk on this version hasn’t closed, and when it does, it lands here - good or ugly.

The call: build vs buy for two niche storefronts

My distribution client runs a portfolio of storefronts, and two of the niche ones (about 215 orders a year combined) need to talk to the ERP. The off-the-shelf answer is an integration connector, and connector pricing is built for stores doing thousands of orders. Priced per month, against 215 orders a year, the math is indefensible. The other standard answer is handing it to an integration vendor, which trades a subscription for a dependency.

I killed both options and we’re building a small bespoke per-order sync in-house. My time in the whole question: about an hour with the order counts and the quotes in front of me, plus writing the brief. The build is a few hours of agent-team work. Once the call is made, none of those hours are mine. This is the part of the CIO job that doesn’t show up in a feature list: matching spend to volume. The right integration for 215 orders a year is not the right integration for 20,000, and the vendors quoting you will not be the ones to say so. The honest tradeoff: bespoke code is mine to maintain. At this volume, that’s a good trade.

Governance: the pricing bug the ledger never saw

The client’s new retail point-of-sale creates orders in the ERP through an integration, not through the UI. This week an audit pass caught something the ledger never flagged: the workflow that prices the intercompany purchase behind each retail sale only fires on UI saves. On integration-created orders it did nothing. No error, no log entry. Every affected transaction since go-live was priced at cost.

I made the call on the fix (move the pricing logic into the integration path itself rather than patch the workflow) and delegated the build to my AI agent team. Same day: implemented, verified against a live transaction to the cent, and the historical damage quantified at $1,423.74, itemized so accounting corrects it with a single journal entry. The lesson I keep relearning: the expensive failures are the silent ones. Nobody reconciles the ledger hunting for a bug that produces no errors. That’s why auditing that systems tell the truth is a standing part of the job, not a project.

The long game: storefront migration, round two

The bigger arc this week isn’t a bug fix. Last spring we rebuilt the client’s flagship storefront for $25K against a $36K agency quote that covered less. Now the second retail brand is moving onto the same platform, and this week the unglamorous foundation went in: the catalog scoped to the 6,123 items the store should actually carry, store-level product fields added to the ERP so one catalog can serve multiple storefronts cleanly, and the integration vendor pointed at the new data feed. On top of that, more than 7,000 catalog items got SEO titles, meta descriptions, and product metadata generated and applied, the kind of job that swallows a content team’s quarter.

Migrations don’t fit in a week, and most of the work is invisible until the end. I’ll keep reporting this one as it moves. The cutover is where the receipts land.

The flagship storefront got a full SEO audit the same week: 38 dead URLs that search engines were flagging now redirect to their live pages, product listings picked up the structured data that makes ratings and pricing show in search results, 25 page titles were rewritten for click-through, and a channel-attribution bug in the analytics was traced to its actual cause.

Also in flight on the same storefront portfolio: the lifecycle email program launched last week is now fully live: reorder reminders timed to each product’s supply cycle, 5,243 chronically dead subscribers suppressed to protect deliverability, two A/B tests running. Measurement is scheduled to run itself in early August and early September. I don’t have the revenue number yet, and I’ll post it either way.

Working capital, meanwhile

Collections follow-up became an engine this week: every morning at 5:30 it sweeps open invoices and emails each customer’s own billing contacts at the right reminder thresholds. I set the policy: thresholds, recipients, and a dry-run gate. My agent team built the engine and ran it in dry-run until its output matched the ledger. Then I flipped it live. The judgment calls in collections stay human - the reminders never needed to be.

My consulting client

My other client is my own consulting practice, and it gets the same treatment as the paying one. This week: a complete overhaul of the practice’s web content, and prep for a big sales meeting (two calls with a major ERP vendor’s sales team, demoing how I wire AI directly into their platform). The practice also got a content engine: the week’s actual work (commit history, project logs, this calendar) gets drafted into this log, I review and edit, and I reply “publish” to an email to put it live. The same machine already answers the practice inbox. Client zero.

Who did what this week: every meeting above, the build-vs-buy call, the audit habit that caught the pricing bug, the store-count requirements, and the collections policy were mine. No agent sits in on those calls. The store-inventory app, the pricing fix, the collections engine, the SEO audit, the 7,000-item enrichment, the migration groundwork, the web content overhaul, and the first draft of this very note (assembled from the week’s commit history, project logs, and calendar) were the agent team’s, working from my briefs. Everything is thoroughly tested and reviewed before it ships, by the team’s QA gates and by me. Nothing ships, or publishes, without my sign-off.

---

The context, if you’re new here: this is a part-time engagement, and everything above (the decisions and the delivery) happened in one week alongside the run-the-business work. The traditional model staffs the execution with a team of specialists and a project manager. My AI agent team is that team. I supply the judgment. How that works is here. If you have a big backlog of projects and a small budget, let’s talk. We crush budgets and timelines. Come back next week.