Matt Jesuele

I’ve spent about fifteen years building production software. I also build trading infrastructure and research tooling for my own use, and I studied economics and philosophy as an undergraduate.

The same questions keep showing up across those areas: what can we infer from the evidence we have, which assumptions are doing the work, how confident should we be in the conclusion, and what would make us change our mind?

Those questions become very practical inside an investment process. Research depends on data, models, source material, software and human judgment. The systems around that work can affect how efficiently it gets done, which questions are practical to ask, whether prior reasoning survives as evidence changes, and how clearly the team can see what its conclusions actually rest on.

When I look at a research process, I’m interested in more than whether it can be automated. I want to understand what the team is trying to learn, what the available evidence can support, where important assumptions or comparisons remain implicit, and where the existing tools make useful work harder than it should be.

Sometimes the useful answer is new software. Sometimes it is an integration, making an existing tool dependable enough for daily use, or changing the workflow instead. I don’t start with a preferred solution; the answer should follow from the problem.

I’ve been building software for about fifteen years, including as the first employee at DoltHub, in technical leadership roles, and running my own software business. My work has ranged from product and infrastructure engineering to the trading and research systems I build for myself.

I earned a B.A. in Economics and Philosophy from Rutgers, summa cum laude in three years, and later completed a certificate in quantitative finance at Columbia.

Ansatz is principal-led. I’m the person who understands the problem, proposes the approach, and does the work.

I usually start with a real workflow or research problem. If I think there is something useful to do, I’ll send back a short view of the problem and how I’d approach it. From there, we can scope a bounded first piece of work.

I’m not committed to custom software as the answer. Sometimes the right intervention is choosing or configuring an existing product, an integration, a workflow change, or making something the team already has more dependable. First sprints are generally $5–10k over roughly two weeks; smaller engagements can make sense for a useful result with clear dependencies.