The Field Theorist's Guide to Startups

Someone once told me I don't operate like a founder. I operate like a field theorist who accidentally ended up running a company.

At first, I wasn't sure if that was a compliment. Most founders optimise for momentum, fundraising, and narrative. They think in features and market positioning and competitive moats. They pivot when something doesn't work. They pattern-match to what's worked before.

I've never been able to do any of that naturally.

When I'm stuck, I don't pivot. I generalise the problem until the constraint disappears. I don't think in feature terms-I think in axioms and transformations. Most founders treat product as a path to revenue. I treat product as an attempt to formalise a worldview.

This has made things harder in some ways. VCs pattern-match, and I don't fit the pattern. Enterprise buyers want simple narratives, and my explanations tend toward "let me show you why causation isn't the same as correlation, starting from first principles."

But it's also why we've built something that shouldn't exist. We solved a 40-year-old complexity barrier in causal discovery. We made enterprise-scale causal AI possible. And we did it with a small team, bootstrapped, while everyone who understood the problem said it couldn't be done.

Here's what I've learned about building companies when your brain works like a theorist's.

I. The Cold Start Principle

My PhD was about cold start problems in machine learning-making accurate predictions with minimal initial data.

Motors in a factory don't produce convenient training datasets. Failures are rare. Data is messy. And you can't wait years to collect enough examples. I had to build systems that could learn to detect faults from almost nothing, then generalise across different motors without retraining.

What I didn't realise at the time was that I was studying my own operating mode.

At 24, I launched into enterprise sales to Fortune 500 companies. No sales experience. No playbook. No established network. Just the belief that if the problem was real and the solution worked, I could figure out the rest.

I co-founded a consultancy during my PhD-bootstrapping a business while still a student, using client problems to pressure-test research ideas. I built a company that competes with Palantir with a founding team of four people.

Most people need extensive ramp-up, established playbooks, large teams. I seem to be more comfortable in cold-start conditions than in steady-state ones. The chaos of bootstrapping feels more natural than "normal" work.

This isn't a humble brag. It's a diagnostic. If you're wired this way too, you should know it-because it shapes everything about how you should build a company.

Cold-start people are bad at optimisation. We're good at existence proofs.

II. Axioms, Not Features

The first time I sat in a product meeting and someone asked "what features should we build next quarter," I realised I didn't think in those terms at all.

I think in axioms and transformations.

An axiom is a foundational assumption. In causal inference, one axiom is that causes precede their effects in time. Another is that if you can block all paths between two variables, they become independent. From a small set of axioms, you can derive an enormous amount of structure.

A transformation is how you move from one state to another while preserving what matters. In our causal discovery algorithm, the transformation is: given a current graph structure and new statistical evidence, how do you update the graph while maintaining consistency?

Features are endpoints. Axioms are generative.

When a customer asks for a feature, I find myself asking: what's the underlying need? What axiom would satisfy not just this request, but the entire class of requests like it?

This drives product managers insane. But it's why we can serve manufacturing, financial services, logistics, pharma, and telecommunications with essentially the same core engine. We didn't build features for each industry. We built axioms that apply across them.

The practical translation: before you build anything, ask what the minimum set of true statements is that would make this problem-and all problems like it-solvable. Then build those.

III. Generalise, Don't Pivot

The startup playbook says: when you hit a wall, pivot. Try a different market. Change your positioning. Abandon what isn't working.

I've never been able to do this. When I hit a wall, I don't pivot-I generalise the problem until the constraint disappears.

Here's what I mean.

Early in RootCause, we hit a fundamental barrier: traditional causal discovery algorithms scale O(n²) with the number of variables. For enterprise datasets with hundreds or thousands of signals, this meant compute times measured in decades. The literature said this was a fundamental limit.

Most startups would have pivoted. "Okay, causal discovery at scale is impossible, let's build a simpler correlation tool instead."

We asked: why is it O(n²)? What specific operations create that complexity? Can we find a different computational path that achieves the same result?

It took years. But we found it. O(n log n) causal discovery using precomputed distance correlation matrices and Schur complement updates. The constraint didn't disappear because we avoided it. It disappeared because we generalised our understanding of the problem until we could see around it.

This isn't always the right approach. Sometimes the wall is real and pivoting is correct. But if you're a field theorist by temperament, your comparative advantage is exactly this: the ability to sit with a problem long enough to see the shape of the solution space, rather than pattern-matching to existing solutions.

IV. The Imposter Problem

I have imposter syndrome about theory.

This is ironic, because I have a PhD and have published papers. But I came from applied AI. I made things work empirically before I understood why they worked. I assumed the "real" theorists-the Judea Pearls and Elias Bareinboims of the world-were fundamentally smarter than me.

Here's what I've learned: the deepest theoretical insights almost always come from people who spent years staring at empirical anomalies that the existing theory couldn't explain.

Darwin was a naturalist. Faraday was a bookbinder's apprentice who did experiments. Einstein was a patent clerk looking at clocks and trains.

The pure theorist, sitting in an office deriving from first principles, typically produces elegant frameworks that work in simulation and fail on contact with reality. The applied researcher who keeps asking "why doesn't the theory match what I'm seeing?" is the one who eventually rewrites the theory.

My PhD was on anomaly detection in motors. I kept noticing that the "noise" in sensor signals carried structure-that what the textbooks called random variation was actually deterministic information leaking through from unobserved causes. This led to our work on latent confounder recovery, which achieves 46% better performance than state-of-the-art methods.

That's not engineering. That's theory. It just came from a different direction.

If you're an applied person with theoretical ambitions: the path is open. Your empirical anomalies are your data. Your "this shouldn't work but it does" moments are your research program. Write them down.

V. The Communication Problem

Field theorists are bad at pitching.

When someone asks "what does your company do?", my instinct is to explain the structure of the problem space, the limitations of existing approaches, the key insight that unlocks the solution, and how that insight generalises to an entire class of problems.

This takes about 45 minutes. VCs have 30.

I've had to learn, painfully, that most people don't want the derivation. They want the result. "We make causal AI 876,000 times faster" lands better than "we achieved O(n log n) complexity through precomputed distance correlation matrices and low-rank Schur complement updates for conditional independence testing."

But here's the thing: the right investors, customers, and hires do want the derivation. The people who will really get it-who will stick around for the hard parts, who will see the long-term value-are the ones whose eyes light up when you explain the actual mechanism.

So I've developed a two-stage approach:

Stage one: The result. "100 years of compute time reduced to 1 hour. Here's a customer who used it. Here's the before and after."

Stage two: For those who lean in-the derivation. The full picture. The axioms and transformations.

The first stage gets you in the door. The second stage is where you find your people.

VI. Building a Category vs. Winning a Market

I'm not trying to win a market. I'm trying to create a category that no one else is equipped to define.

This sounds grandiose. It's not meant to be. It's a statement about strategy.

If you're competing in an existing market, the playbook is clear: differentiate on price, features, distribution, or brand. Find your niche. Execute better than the competition.

If you're creating a new category, none of that applies. You're not differentiated from competitors-you're explaining why the comparison doesn't make sense. You're not finding a niche-you're defining the territory. You're not executing better-you're making a different thing possible.

When people ask how we compare to Palantir, I have to explain that Palantir does correlation. We do causation. These are not points on the same spectrum. They're different mathematical objects with different capabilities and different use cases.

This makes sales harder in the short term. But it makes defensibility permanent.

Palantir can't become us by adding features. They'd have to rebuild from the foundations up. The same is true for every business intelligence tool, every traditional analytics platform, every machine learning company that does prediction without understanding causation.

We didn't choose this position for strategic reasons. We chose it because it's the only honest description of what we built. But it happens to also be the most defensible position you can occupy.

VII. The Minimum Viable Organisation

I think of RootCause as the minimum organisational vessel that can carry the idea I actually want to explore.

This is a weird way to think about a company. Most founders think of the company as the goal and the product as the means. I think of the research program as the goal and the company as the means.

The company exists because:

• • You can't do causal discovery research without real enterprise data
• • You can't get real enterprise data without customers
• • You can't get customers without a product
• • You can't build a product without a team
• • You can't sustain a team without revenue

So we built a company. But the company is infrastructure for the research, not the other way around.

This has practical implications. We don't build features that don't extend our theoretical capabilities. We don't take customers whose problems don't teach us something new. We don't hire people who just want to execute-we hire people who want to discover.

I realised early that the filter for hiring should be: "Is this person here for the discovery, or just for the outcome?"

Our CPO had co-founded npm, raised over $125 million, built companies to $150 million ARR. He could be doing anything. He joined after seeing the technology-not the market opportunity, not the team. Because he recognised it as something new, something that needed to exist.

That's the signal. When someone who could do anything chooses to work on your problem, you're probably onto something real.

VIII. What Physics Taught Me

I don't have a physics background. But I've come to understand why physicists make good startup founders.

Physics teaches you that the universe has structure. That messy observations reduce to clean laws. That apparent complexity often hides deep simplicity.

Most importantly, physics teaches you that being stuck is not failure-it's information. If the theory doesn't match the observations, the theory is wrong. And finding exactly how it's wrong is the key to finding what's right.

Every wall I've hit in building this company has eventually revealed a gap in my understanding. The inability to raise from VCs revealed that I was communicating poorly. The difficulty of enterprise sales revealed that I didn't understand how buyers think. The limitations of our early algorithms revealed mathematical structures we hadn't yet discovered.

None of these were dead ends. They were data.

The field theorist's approach to startups is: treat every failure as an observation. Figure out what theory would predict that observation. Then find the better theory that predicts both the failure and the success condition.

It's slower than pattern-matching. But it's more robust. And it leads to places that pattern-matching can never reach.

Coda: The Question I Haven't Answered

Once RootCause reaches steady-state operations-mature product, established customers, stable team-will I still find it energising?

I don't know.

I've been working seven days a week since 2021. This doesn't feel unusual to me. The chaos of building something new, the constant cold-start problems, the theoretical puzzles embedded in practical challenges-this is where I'm comfortable.

What happens when the puzzles are solved? When the system runs itself? When there's nothing left to generalise?

Maybe I'll manufacture new cold-start problems within the company. Maybe I'll start something new. Maybe I'll finally write down all the theory that's still in my head.

What I know is that the field theorist's path doesn't end when the company succeeds. It just reveals the next level of questions.

And that's probably the point.