I've been building software for thirty years. Heuron is what I do with that now.

Most of my career has been spent inside organizations where the software is the operation — market data systems, trading infrastructure, a financial systems company I co-founded and sold. When the software is wrong in those places, the business stops. You learn to be careful in a particular way.

Heuron Technology is where I bring that to firms that are much smaller and, as far as I can tell, much worse served.

Why firms your size, specifically

Large organizations get software built for how they actually work. It's expensive, it takes a year, but they get it. A firm of thirty people — an accounting practice, a law firm, an agency — gets told to buy a product and adapt to it. Then it spends the next decade absorbing the difference between what the product does and what the work actually requires, using spreadsheets, email, and one person who remembers the steps.

For a long time that was economically rational. Custom software cost more than the problem was worth at that scale, so nobody built it. That stopped being true about two years ago, and most of the industry hasn't repriced yet.

The work that used to justify four developers for most of a year now takes weeks. I built the practice around that, rather than around defending an old rate card.

The through-line across the firms I work with isn't the industry — it's the shape. You bill for your people's time. Your process is real and mostly undocumented. You're the right size to have genuine operational complexity and the wrong size to have anyone whose actual job is software.

Two halves of a career, and why both matter

I spent the first twenty-five years in startups and product companies, where shipping was the entire job and nobody was coming to help. I've spent the last seven inside very large organizations, where shipping means getting through security review, change control, and an audit trail.

Most consultants have one of those. Having both is the actual reason a firm of thirty people can hire one person and get something that works and holds up.

The part that makes the arithmetic work

Since early 2026 I've been building the infrastructure that lets AI coding agents do real production work without the usual result — a large pile of plausible code that nobody understands and nothing verifies.

The system is called code-coordinator. It runs agents across machines through a pipeline where every stage is itself agent-driven — plan, work, test, review, merge — and where failures loop back rather than proceeding. Nothing merges on an agent's own account of whether it worked. It's open source, and it's what I use on client engagements.

To prove it out I've used it to build things far larger than most client projects: a 137,000-line modal text editor in Rust with over five thousand tests, and the cross-platform UI library underneath it. Roughly 3,500 commits since February. That work isn't for sale — it exists so that I know, in detail, where this approach holds and where it falls apart.

Which matters to you only in this way: it's why I can quote a fixed price on a real system and not lose money on it.

What I'm like to work with

I'll tell you when you shouldn't build something. If there's an off-the-shelf product that genuinely solves your problem, I'd rather point you at it and keep the relationship than take a project that shouldn't exist. This has cost me work and I intend to keep doing it.

I write things down. Scope, acceptance criteria, assumptions, price — all agreed in advance, in a document, before anyone starts. Most of what goes wrong in software projects goes wrong because two people believed different things and neither wrote it down.

And you get me. Not a team you meet once during the sale. The same person does the discovery, writes the code, and answers the phone two years later.

Not every firm needs something built

Some just need a technical person in the room — for the vendor contract nobody can evaluate, the security questionnaire a client sent over, the build-or-buy call, the question of what to actually do about AI as distinct from what everyone says about it.

I take a small number of those on retainer, a day or two a month. Fractional CTO is the term for it. It's the same work as everything else here, in a different arrangement, and it usually starts because a firm hired me to build one thing and then kept asking questions.

Outside of that

I live in Minneapolis. Outside of work I spend a fair amount of time on music production, which turns out to use the same part of the brain as system design — a lot of small decisions that only matter in combination.