Things we think are worth writing down.

Why We Don’t Take Venture Capital

We get asked about this with surprising frequency, usually by journalists and sometimes by founders who are weighing the same question themselves. The short answer is that VC funding and the kind of software we want to build are in fundamental tension - not philosophical tension, but structural, incentive-driven tension that compounds over time.

Let's start with what venture capital actually requires. A VC fund raises money from limited partners - pension funds, endowments, family offices - with the promise of returns that beat the market. That requires portfolio companies to exit at large multiples. That requires large exits to happen on a timeline that works for the fund's lifecycle, typically 7 to 10 years. That means the companies in the portfolio are not being optimized for product quality, user trust, or long-term sustainability. They are being optimized for growth trajectory and exit potential.

This is not a criticism of the people involved - it is a description of the system. Venture partners have obligations to their LPs. The companies they fund have obligations to their investors. These obligations are real and binding, and they shape every major product decision whether or not anyone in the room acknowledges it explicitly.

What it does to product decisions

The clearest symptom is what growth pressure does to a product's core purpose. When a software company needs to demonstrate user growth, it adds features for users it does not currently have. It broadens its scope to attract adjacent markets. It acquires smaller companies to accelerate user counts. It pivots when a different market looks larger. Each of these decisions is rational given the incentives. None of them is oriented toward making the existing product better for the people who already depend on it.

The second symptom is timeline compression. Venture-funded companies are under pressure to ship - to show momentum, to hit milestones that satisfy board members and set up the next round. This pressure is antithetical to the kind of deliberate, careful product work that produces professional software. Professional software needs to be right, not just fast. Meridian's compliance accuracy cannot be 95% because 95% means that 5% of flags are wrong, and architecture firms cannot build their compliance process around a tool that sends them to the AHJ with errors. Getting from 95% to 98.2% took time we could not have spent if we were racing to a Series B.

The 10-year horizon

Self-funding changes the time horizon entirely. When the business is profitable and has no external obligations, decisions can be evaluated against a 10-year window. That means investing in technical foundations that won't need to be rebuilt in three years. It means passing on feature requests that would dilute the product's focus. It means taking six months to get something right instead of two months to get something shipped.

The tradeoff is pace and scale. We grow slower than a venture-funded company would. We have fewer users today than we would with a paid acquisition budget. But the users we have trust the products in a way that matters - not the fragile trust of users who don't yet have alternatives, but the durable trust of professionals who have tested the products against their real work and found them reliable. That trust is the product of time, and time is what self-funding buys.

We are not principled opponents of venture capital as a financial instrument. It is the right tool for some businesses. It is the wrong tool for building software that professionals can trust over a decade. For that, the math works out differently - and we have run the math.

On Shipping Software That Admits What It Doesn’t Know

There is a temptation in AI product design to project confidence. Confidence feels like a feature. Users want tools that appear decisive, tools that tell them the answer rather than making them think harder. The instinct is to suppress uncertainty - to round up, to present outputs as conclusions rather than observations, to hide the error bars.

We think this is wrong, and we think it is particularly wrong for the kinds of products we build. Meridian flags compliance issues in architecture drawings. Helix identifies health trends in longitudinal biomarker data. In both domains, what the software does not know is as important as what it does know - and pretending otherwise is not just a philosophical failure. It has real consequences.

Meridian: confidence on every flag

Every flag Meridian generates carries a confidence score. Not a generic "high/medium/low" classification - a specific, calibrated score that reflects the model's actual certainty about whether this element is non-conformant with the referenced code section. When the score is high, the flag is almost certainly a genuine issue. When the score is lower, the flag warrants human review before being acted on.

The decision to show this score was not universally supported during development. The argument against it was intuitive: showing uncertainty might make users trust the product less. If Meridian says it's 73% confident about a flag, doesn't that undermine the flag's credibility?

The argument for it was more important: architecture firms are making consequential decisions based on Meridian's output. They deserve to know when the model is confident and when it is not. Hiding that information does not make the underlying uncertainty go away - it just means the firm acts on it without knowing it exists. That is the worse outcome. A 73% confidence flag that an architect reviews and confirms is more reliable than a 73% confidence flag that got rounded up to 100% and shipped to the AHJ unchecked.

Calibrated uncertainty also improves over time. Because Meridian shows confidence scores and users can validate or dismiss flags, we have a feedback loop that helps us understand where the model is systematically overconfident or underconfident. That data has been essential in getting from 95% accuracy to 98.2%. Systems that hide their uncertainty cannot improve in this way - they have no signal about where the errors are.

Helix: noticing, not diagnosing

The design constraint in Helix is different but related. Helix identifies patterns in health data. It surfaces trends - a declining HRV over 90 days, a shift in resting heart rate that correlates with changes in sleep quality, a lab value that has moved steadily outside your personal baseline for six months. These patterns are real and meaningful. They are also not diagnoses.

Helix does not tell you what a trend means clinically. It does not tell you what to do. It tells you what it noticed - clearly, with enough context to evaluate whether the observation is significant, and with the strong suggestion that findings worth acting on should be discussed with a physician. That boundary is not false modesty or legal caution. It is honest about what Helix is and is not.

Consumer health apps have spent a decade eroding the boundary between observation and diagnosis in ways that are occasionally useful and frequently harmful. An app that shows you a HRV trend and then tells you "this might indicate cardiovascular risk, consider speaking with a doctor" has done something different from an app that just shows you the trend. The first has interpreted the data clinically. The second has handed you a observation and left the interpretation to the appropriate party - you and your physician.

The general principle

Admitting what software does not know is not a weakness. It is an engineering requirement for products that professionals trust with consequential decisions. The alternative - software that projects false confidence, that rounds up uncertainty, that presents observations as conclusions - is software that will eventually fail its users in a way they did not see coming. The confidence was not real. They just couldn't tell.

We build products for people who cannot afford that kind of surprise. So we show the confidence scores. We surface the uncertainty. We tell users what the model noticed, not what it concluded. And we trust that professionals who are given honest information are better equipped to make good decisions than professionals who are given confident-sounding guesses.