There is a concept in investment management called the difference between return and risk-adjusted return. The first tells you how much a portfolio gained. The second tells you how much of that gain came from skill versus from taking on exposure that could have gone the other way just as easily. The two numbers can look very similar in a bull market. They diverge sharply when conditions change.
I spent more than two decades in investment and portfolio management, most recently at Richmond Capital Management. Before I left to build Flowlinx full-time, most of my working hours were spent on a version of the same question: how do you tell the difference between something that is genuinely valuable and something that merely looks valuable right now, under current conditions? That discipline turned out to be far more useful in building AI software than I expected.
Capability without reliability is a liability
The AI landscape right now rewards demos. A compelling demonstration of what a model can do — a complex task performed fluently, a surprising output that lands perfectly — generates enormous attention. That attention often translates into funding, customers, and momentum. The problem is that demonstration capability and deployed reliability are different measurements, and the gap between them is where most AI software actually fails.
A system that works ninety percent of the time in a controlled demo can be genuinely impressive. That same system, running in a real business workflow where people depend on it daily, will generate one failure for every ten tasks. Compounded across a team, across weeks, that failure rate is not impressive — it is a drag on the work it was supposed to help with. Users stop trusting the system. They start working around it. Eventually they stop using it.
In investing, we call something like this a liability hidden in plain sight — an apparent asset that is creating risk rather than value, visible only to people who look past the surface. Capability without reliability is exactly that: an apparent feature that becomes a structural problem at scale.
How portfolio discipline shapes how I build
The CFA curriculum is built around a specific kind of rigor: the obligation to measure what matters, to distinguish correlation from causation, and to resist the narrative pull of a compelling story when the underlying numbers don't support it. That rigor runs directly against the grain of much of how AI products are currently built and evaluated.
When I look at a feature at Flowlinx, my first question is not "can we build this?" — in 2026, the answer to that is almost always yes for something. My question is "what does success actually look like for the people using this, and how do we measure it?" That is a different conversation than "how impressive does this look?" and it leads to different decisions. Features that would perform well in a demo but introduce failure modes in sustained use get cut or redesigned. Features that seem less impressive in isolation but make the overall system more dependable get prioritized. The portfolio analogy is direct: you optimize for the system, not the individual position.
The question is not whether it works in the demo. The question is whether it compounds over time for the people using it every day.
Dependability compounds
One of the clearest parallels between investing and software is the power of compounding — and how it applies to trust as much as to returns. A software tool that performs reliably creates a kind of trust capital. Users learn they can depend on it. They build it into their workflows. They give it more work. Over time, the product earns a place in how the business operates that is very difficult to displace, not because of switching costs or contracts, but because the people using it have genuinely shaped their work around it.
That compounding effect is also why unreliability is so costly. Each failure is not just a single bad output — it is a withdrawal from the trust account. At some threshold, users stop extending the benefit of the doubt. They route work around the tool, or they stop using it altogether. The compounding reverses. Rebuilding trust after it has been lost is substantially harder than earning it in the first place.
At Flowlinx, reliability and trust are product requirements in the same way performance and correctness are. We track them with the same discipline we apply to any other quality dimension — because a product that is capable but unreliable is not a product people will build their work around, and that is the only outcome we are interested in.
Measuring real value over novelty
Twenty-plus years of evaluating investments left me with a strong reaction against novelty that isn't connected to durable value. Not because novelty is bad — some of the most important advances start as things that look like novelty — but because novelty without a mechanism for generating real, recurring value is not an asset. It is a story.
I apply the same test to software. The right measure of an AI product is not how impressive the capability looks at launch. It is whether the people using it are genuinely better at their work six months later than they were before. That is a harder thing to optimize for — it requires staying close to real users, measuring outcomes that take time to materialize, and resisting the pressure to ship things that look good before they are dependable. But it is the only measurement that matters in the end.
The dual lens: building and investing
Running Flowlinx and investing at Fifth Turn Capital simultaneously is not the most conventional path, but the two roles inform each other in ways that I find genuinely valuable. Investing gives me a wide view of where the market is heading and what teams are actually building versus what they are claiming to build. Building gives me a ground-level understanding of what reliable AI software requires that I could not get from due diligence alone.
The thing both roles have reinforced is this: in an environment where almost anyone can build something impressive, the durable differentiation belongs to the teams that build something dependable. Impressive fades quickly. Dependable compounds. That is the conviction Flowlinx was built around, and it is the standard I apply on both sides of the table.