Ben

Software Engineer

I build systems
that run themselves.

Automation pipelines, quantitative research infrastructure, and on-device AI applications — in Go, Python, and Swift. Mostly solo, and mostly the kind of work that is judged by whether it still runs correctly six months later.

What I work on GitHub

Focus

What I work on

Three areas, further apart than they look. Each one is really the same exercise: take something repetitive and error-prone, and turn it into a system that does not need supervising.

  • Automation pipelines

    Long-running systems that do the whole job on a schedule, with nobody watching.

    Multi-stage pipelines that chain external APIs, media processing, and storage into one unattended run — including the parts nobody enjoys: retries with backoff, rate limits, partial-failure recovery, and enough logging to tell what went wrong three days later.

    • Go
    • FFmpeg
    • SQLite
    • GitHub Actions
    • REST APIs

  • Quantitative research infrastructure

    Backtesting and validation tooling built to resist the researcher using it.

    Research systems for financial time series where the hard problem is not finding a signal but avoiding a false one. Held-out data that testing cannot reach, look-ahead-bias regression tests, and multiple-testing correction, so a result has to survive something before it is believed.

    • Python
    • pandas
    • NumPy
    • Streamlit
    • MetaTrader 5

  • On-device AI applications

    iOS apps where the model runs on the phone and the data never leaves it.

    Native applications built around Apple’s on-device model and vision frameworks. No inference server means no data egress, no per-user inference cost, and no backend to keep secure — which changes what is reasonable to build for privacy-sensitive users.

    • Swift 6
    • SwiftUI
    • SwiftData
    • Foundation Models
    • Vision

Work

Selected work

Everything I am currently building lives in private repositories, so there is nothing here I can link to yet.

Rather than describe work you cannot inspect, I would rather show you nothing and talk about it directly. Public releases will be listed here as they happen.

Ask me about it

Approach

How I work

  1. Decide how it could be wrong, first

    Before the code, the note that says what result would mean the idea does not work. Written afterwards, that note always somehow agrees with whatever was built.

  2. Unattended, or unfinished

    If it needs me to click something every morning, it is a draft. Done means it runs on a schedule, recovers from its own failures, and only interrupts me when something is genuinely wrong.

  3. Fewer moving parts last longer

    Every dependency is a thing that can break while I am not looking. This site is the small version of that argument: it ships zero runtime JavaScript, so there is no framework in it to go out of support.