Company-Building Under Real Constraints

I have spent close to thirty years building companies that sell software into operations rather than into slide decks. Pine Labs put card-based payment systems into Indian retail. GlobalLogic built product engineering teams for other people’s hardest problems. hCentive built healthcare eligibility and enrollment systems while the rules were still being argued about on cable news. Routespring is now building technology for corporate and airline crew travel — in a part of the industry that still runs on phone calls, email and manual coordination.

Different industries, but the same shape of problem. In each one, the interesting work was never the clean transaction. It was the exception, the concentration, the manual minute, the moment the system says “error” and hands the problem back to a person.

Most startup advice is written for businesses where the product is the whole company and the customer is a diffuse market. Operational software is not that. One customer can be most of the revenue. A workflow that looks automatable falls apart the moment you sit with the people doing it. Services quietly become the product. Enterprise buyers care less about what your software does than about what happens when it fails.

This series is seven notes on building under those constraints:

1. Building when one customer dominates the business
2. Knowing whether a workflow is actually automatable
3. Manual minutes per transaction is better than “AI adoption”
4. Why enterprise software fails at exception handling
5. When services are a wedge — and when they become a trap
6. How enterprise buyers evaluate operational risk
7. What successful exits do — and do not — teach you

None of it is theoretical. All of it is written from the position of an operator who has been wrong often enough to be skeptical of tidy lessons — including my own.