Hidden work always sends a bill

A painful release does not only cost you the hours everyone can see. It charges the business again in delayed customer learning, delayed revenue, and a team that learns to protect its own step instead of the outcome.

In the release process I broke down this week, a rotating four-person effort annualizes to roughly $416,000 in direct labor. That number is staggering, but the headcount is not the real problem. Four people can move quickly when one of them clearly owns the result. Four people can also spend all week handing responsibility to one another.

I call the second version responsibility laundering. Engineering says the build is done. QA says the test passed. Operations says the deployment ran. Somebody else owns the customer message. Every box can be checked while the release itself still fails.

The fastest way to find this tax is to ask three boring questions. Who can say the release is ready? Who can stop it when it is not? Who owns the customer outcome after it goes live? If the answers are a committee, a meeting, or a chain of handoffs, you do not have a technical problem. You have an accountability problem that happens to be collecting payroll.

Then follow the cost downstream. A release sitting in a queue is not merely late. It delays the feedback that tells you whether the work matters. It keeps sales and support waiting for a promise they cannot use. It makes the next decision with less evidence than you should have had.

Do not start by adding another checklist. Name one owner for the outcome, give that person the authority to make the call, and measure the time from ready to customer value. The point is not to make releases look cleaner. It is to stop paying twice for the same work.

I broke down the full example in The Release Tax.

A funding announcement compresses months of work into one number. That is useful for the announcement. It is terrible preparation for the founder who thinks the raise will fit around the rest of the company.

Kevin Callahan told me his fundraise took roughly 1,000 hours once he counted all of the work, including due diligence. That is one founder's experience, not a promise about how every raise works. It is still a useful correction. A serious fundraise is not a side task. It is a temporary operating function with founder-level stakes.

That time has to come from somewhere. If the founder is raising, somebody else has to keep customers moving, decisions getting made, and the team pointed at the right work. Otherwise the company can win the financing process and quietly lose months of operating progress along the way.

The same discipline applies to outreach. Kevin's advice was not to blast an automated message to a thousand investors. Cold outreach can work, but targeted outreach and mass outreach are not the same process. The investor, the reason for the fit, and the next step all need enough thought to deserve a response.

Before starting a raise, write down four things: the work the founder will personally own, the company outcomes that cannot pause, the person who owns each of those outcomes while the raise is active, and the weekly capacity the process is allowed to consume. Then review that plan like any other major operating commitment.

The money in the headline matters. So does the business you still need to run while earning it. Treat the fundraise like a real function, name its owner, and make the tradeoffs before the calendar makes them for you.

Watch the full conversation in Kevin Callahan: Startup Fundraising - What a 1,000-Hour Raise Actually Takes.

If a useful AI workflow only exists inside one vendor's container, you do not own the whole workflow. You are renting part of it.

OpenAI says Custom GPTs are scheduled to retire on December 11, 2026, although the date may differ based on an account or workspace notice. Its migration FAQ and release notes also make the transfer limits clear. The migration uses the latest published version. Unpublished edits do not transfer, and the selected model, conversations, sharing state, and custom actions have material limits. Custom actions do not move automatically.

The important news is not that one product feature is changing. Products change. The business question is whether the work survives when its container does not.

I have seen software migrations stall because the company never committed to finishing the move. The old system stayed alive, the new system remained incomplete, and sales and customers inherited the risk. An AI workflow can fall into the same trap if its instructions, reference material, access rules, and integrations only live inside the old tool.

Before migrating, make a small operating inventory. Name the workflow's owner. Export or rewrite the instructions. Identify the reference material it depends on. List every integration and every person who needs access. Save a handful of representative inputs and the outputs the business considers acceptable.

Then migrate the latest approved version and run those examples through the replacement. Compare the results before changing the process underneath customers or employees. If the outputs differ, decide whether the difference is acceptable instead of discovering it in production.

An exit plan is not vendor panic. It is ordinary continuity work. The goal is not to make every tool interchangeable. The goal is to keep one provider decision from turning a useful workflow into an emergency.

Lowering price is not only a conversion decision. It is a customer-selection decision.

A discount can bring more buyers into range, but it can also bring in customers who need more explanation, more support, more custom work, and more exceptions before they receive value. The contract gets smaller while the obligation attached to it gets larger.

I was talking through this recently and landed on a blunt version: price too low and you can end up competing for customers who do not understand what you do, demand more from the relationship, and make the business harder to run. A shorter customer list at the right price can be a much easier life.

That does not mean higher is automatically better. It means price has to be judged with the customer it selects. Before approving a discount, compare the expected contract value with the work required to earn and keep it. Look at onboarding time, likely support demand, custom implementation, retention risk, and the amount of roadmap pressure the account can create.

Then ask the uncomfortable question: if ten more customers just like this one arrived next month, would the business get stronger?

If the answer is no, the discount is not buying growth. It is buying a larger queue of work that somebody still has to own. Sales may celebrate the logo while product, engineering, support, and customer success absorb the difference.

Founders usually treat price as the last number in a sales conversation. It belongs earlier, alongside the ideal customer and the operating model. A good price does more than recover cost or signal value. It helps select customers whose needs match the company you are actually prepared to run.

Do not ask only whether a lower price closes the deal. Ask which business that price forces you to become after it closes.

A known defect is not automatically the next problem worth solving.

That sentence can sound irresponsible because teams often confuse acknowledging a bug with promising to fix it. Those are different decisions. You can know exactly what is broken, understand who it affects, and still decide that customer and business capacity belongs somewhere else.

I put it bluntly in a recent conversation: it is valid to say a thing is broken, nobody meaningfully cares, and we are not going to fix it. We are not obligated to repair every little thing that does not matter.

The important part is making that choice deliberately. For each defect, look at customer harm, revenue or retention risk, frequency, workaround cost, and blast radius. Then compare the repair with the highest-value work it would displace. A rare annoyance with a simple workaround should not automatically outrank a problem blocking a customer from buying, renewing, or using the product.

Record the decision in plain language. Name the defect, the evidence, why it is being left alone, and the condition that would trigger another look. That condition could be a second affected customer, a lost deal, a support threshold, or the removal of a workaround. Give the decision an owner so neglect cannot disguise itself as prioritization.

This is not permission to let quality collapse. It is a way to keep quality connected to outcomes. A backlog with a thousand open bugs tells you almost nothing. A short list of defects tied to actual customer and business risk tells you what deserves attention now.

Every fix carries an opportunity cost. Spend that capacity where it protects revenue, retention, or the customer's ability to get value. Leave the harmless rough edge alone until the evidence changes.

Remember that perfect is the enemy of good - just keep making progress. See you next week.

- Hunter