Operating Notes
Concrete decisions from real systems.
Not generic founder advice. When to automate versus standardize, how enterprise accounts distort a company, whether AI is removing work or only moving it, how to manage customer concentration, and how to know when a pivot is failing.
Company-Building Under Real Constraints
A seven-part series on building operational software companies — customer concentration, automation, exception handling, services, enterprise risk, and what exits do and don't teach. Written from the operator's chair, not the slide deck.
- 1
Building when one customer dominates the business
Concentration isn't the real risk — failing to convert a dominant customer into reusable product is. The metric that matters isn't percentage of revenue. It's percentage of the business that could transfer to another customer.
- 2
Knowing whether a workflow is actually automatable
Every workflow looks automatable from a distance. Up close it's a sequence of judgments, not clicks. Five questions to ask before you automate anything — and why the process that works 80 percent of the time is the most dangerous kind.
- 3
Manual minutes per transaction is better than "AI adoption"
"AI adoption" is one of the least useful metrics in software. Manual minutes per transaction is hard to fake, captures hidden labor, and separates adopting AI from actually improving operations.
- 4
Why enterprise software fails at exception handling
Enterprise software is designed around states. Real operations happen between them. Why systems fail at the moment users most need help — and the four capabilities good exception handling requires.
- 5
When services are a wedge — and when they become a trap
Services can be the only credible way into a complex industry, or the thing that caps your margins forever. The distinction isn't whether humans are involved. It's whether their effort compounds.
- 6
How enterprise buyers evaluate operational risk
Founders assume buyers are evaluating the product. They're also evaluating what happens when it fails. Why an inferior incumbent keeps winning, and how to sell controlled change instead of pure improvement.
- 7
What successful exits do — and do not — teach you
An exit gives a founder credibility, not certainty. What building and selling companies actually teaches — and why a previous exit can quietly become a liability.
Other notes
-
Build versus buy is really a question about who owns the interface
The standard framing — compare the cost of building to the cost of buying — misses the question that actually decides it: does the vendor's product expose the interface you need, or just the outcome?
-
The first question in any outage: whose system is it?
Most production failures in integrated systems aren't yours or theirs. They're the handoff between the two, and that's exactly where nobody looks first.