How much of the feedback on a release actually needs to block it?

David Rasch looks for the checks his team can automate so nobody has to keep thinking about them. If an agent repeatedly makes the same mistake, a deterministic check can catch it before a person spends another review pointing it out. That leaves the person reviewing the work to decide what matters.

We talk about where to spend that judgment: the data model, changes to the interface, and the parts of a system that need careful design. Code may be easier to replace now, but someone still has to understand what the software is supposed to do.

David gives an example of an AI review getting caught up in a race condition for a task that runs about once a month. In that case, he decided the extra complexity wasn't worth it. I share an experiment where repeatedly responding to review feedback left my project unable to do anything at all.

The useful question is what needs fixing before this release, and what can become a separate ticket whose priority you decide later. A patient reviewer can always find more work. You still need a person who can decide when the work is worth doing.

Useful questions from the conversation

Which repeated review comments could become automatic checks?

Which parts of this change need someone to understand the design?

Does this issue need to stop the release, or can you decide its priority separately?

Chapters

00:00 When AI agrees with everything

00:12 Meet David Rasch

02:12 What you still need to understand

05:02 Data foundations before more code

10:00 Building and selling as an engineering education

14:42 Which parts need careful design?

19:12 Automating repeatable review checks

21:20 Code is easier to rework

22:31 When review becomes a loop

25:02 Human judgment and work worth doing

28:55 Where to find David

Find David: https://www.linkedin.com/in/rasch

Listen to Episode 36 of Build & Break Through: https://buildandbreakthrough.riverside.com/e/making-ai-useful-with-david-rasch

What would help your customers more: another round of faster AI output, or a better way to see what you're building?

Josh Colter, the majority owner of Cardboard, has put a lot of thought into that question. He bought the company with a bet on AI and has been combining story maps with detailed instructions so he can see the big picture while the models work through the details.

His comparison comes from the Wright brothers. He says "they thought about control first." A bigger engine is useful once you can steer. Josh applies that idea to building software: make the work visible, understand the customer behavior you're trying to change, and keep releases small enough to inspect.

We talk about the difference between having AI drive and learning to operate it yourself, why a long specification can hide something a human needs to see, and how Josh planned and shipped dark mode in three days after finding years of requests from users of a competing product.

Useful questions from the conversation

Can you see the work clearly enough to tell where it's going?

Can the people building it understand the plan as readily as the AI can?

What customer request are you trying to meet, and how will you check the result?

Chapters

00:00 Control before thrust

00:45 Show intro

00:53 Meet Josh Colter

01:26 Buying Cardboard and betting on AI

02:46 Chauffeurs and airmen

08:47 Why a bigger engine needs control

11:05 Make the work visible

15:20 Story maps, specifications and human understanding

20:32 Planning and shipping dark mode

25:26 Checking what you've actually built

26:35 Where to find Josh and Cardboard

In this episode, Brandon Valentine, a CPA and the founder of Valentine Advisory Group, explains why a founder who can't speak to their unit economics can't raise capital: lenders and investors want to understand how the company makes money and how they get their capital back. He breaks down what goes into the numbers (cost of goods sold, operating expenses and a price the market will pay), why pricing starts with market research and the problem you solve for the customer, and how a three statement financial model turns "I want money because my idea is very good" into a specific ask backed by numbers. Hunter adds why bad unit economics get worse with growth: lose money on one widget and you lose more on a thousand. They also cover finance tools versus finance expertise, how to vet a CPA, and how AI is changing accounting work, including why it still depends on good data going in. Founders preparing to raise will learn which numbers to get right before the pitch.

Chapters

00:00 Asking for capital with numbers, not belief

00:37 Introducing Brandon Valentine and Valentine Advisory Group

01:11 Where founders should start: unit economics

03:40 Why you can't raise without your unit economics

04:53 Labor, operating expenses and early foundations

06:55 Bad unit economics lose more as you scale

07:40 Pricing, freemium and market research

10:16 Pricing to the problem you solve

12:50 The three statement model and the capital ask

15:03 Finance tools versus finance expertise

16:33 How to find and vet a CPA

18:07 How AI is changing accounting and finance

23:02 Where AI goes wrong: bad data in, bad data out

24:23 Where to find Brandon

Host: R. Hunter Harris

https://www.linkedin.com/in/rhunterharris/

Guest: Brandon Valentine

Brandon is a CPA from Atlanta and the founder of Valentine Advisory Group. He helps people buy and sell businesses in the lower middle market and helps founders and small business owners build their accounting and finance foundations.

https://www.linkedin.com/in/brandon-valentine-cpa

https://valentineadvisorygroup.com/

By Hunter Software Consulting

https://huntersoftwareconsulting.com/