I started programming around 12 years old, building Minecraft servers, mods, and Java plugins. Bukkit, Spigot, and Paper were my first real engineering environment: event-driven systems, schedulers, persistence, permissions, APIs, JVM behavior, profiling, and performance under real users.

Minecraft was also where I first learned the product side of software: build something people need, then make it something they actually want to use. Under the name FrostyShotz, I published plugins used by server owners around the world. CometWelcome passed 11,000 downloads.

In 2025, I returned to that space with NeON, a modern Paper join/leave system where I was experimenting with animated player holograms, MiniMessage/HEX styling, particles, fireworks, sounds, titles, action bars, and boss bars. What started as childhood plugin development became one of my earliest real feedback loops for shipping software to strangers, watching what they used, and iterating toward utility and delight.

I also ran public Minecraft servers and communities of my own. One of them, Comet FreeBuild, is long defunct, but a few time capsules are still online: the old server website, its Planet Minecraft listing, and an old server video. Building and operating servers gave me an early taste of the full product loop: infrastructure, custom plugins, moderation, community design, presentation, and keeping something running for real users.

I did not attend college and do not have a degree. My education has been self-directed through source code, documentation, research papers, experiments, reverse engineering, benchmarking, and years of building systems that had to actually work.

I tend to think across abstraction layers. Technical language is not decoration to me. Terms imply mechanisms, contracts, invariants, and failure modes, and I usually keep descending until those are explicit enough to build against.

flowchart LR
    A["Understand"] --> B["Model"]
    B --> C["Build"]
    C --> D["Measure"]
    D --> E["Stress"]
    E --> F["Refine"]
    F --> D
    F --> G["Verify"]

Build from first principles. Measure the real system. Keep the evidence.

Desktop-first AI development environment built from OpenCode.

One of my largest systems projects. I work across the application stack:

agent tooling · concurrent sessions · server projections · SQLite · Electron · browser automation · usage accounting · model routing · mobile/PWA · performance

I have also developed a substantial first-party tool surface inside OpenFork:

project · symbols · test · typecheck · refactor · patch · background · swarm · browser · checkpoint · Git · SQLite · SymPy

Performance work is benchmarked against real workloads, including large histories, 50,000-node project trees, hundreds of models, throttled Chromium, concurrent sessions, and high-contention workloads.

OXP · getMCP · localMCP-chat · openswarm

A continuing body of work around giving AI systems powerful local capabilities without giving them uncontrolled authority.

flowchart LR
    A["AI agent"] --> B["Capability layer"]
    B --> C["Authority"]
    C --> D["Filesystem"]
    C --> E["Processes"]
    C --> F["Tools"]
    C --> G["Sessions"]
    C --> H["Delegation"]

Across OXP, getMCP, localMCP-chat, and openswarm, the recurring problems are:

• scoped filesystem authority
• replay-safe mutations
• execution and cancellation
• process-tree lifecycle control
• capability revocation
• provenance
• durable background work
• multi-agent coordination
• permission propagation
• external tool aggregation

getMCP even explores a transport where an agent capable only of reading URLs can operate a controlled coding environment, with the URL itself acting as the RPC surface.

Creative software for technical communication.

I founded PresGen to explore what presentation software looks like when treated as a serious creative engineering environment.

It combines ideas from Illustrator, motion software, scientific visualization, and traditional presentation tools:

vector editing · animation · rich text · LaTeX · graphing · chemistry · SVG · PDF · PPTX · Electron

That work has also produced deeper systems such as ForgePrint, a browser-native engine that converts the live DOM and CSSOM into semantic PDF primitives instead of rasterizing the page.

ArcFit · ESPACK · ESON · ESB64 · ESHTTP · ESARR · ESSTR · ESTIMER · ESCHARS

Working deeply with Illustrator exposed two classes of problems.

First, packaging geometry. ArcFit provides deterministic artwork warping based on the physical dieline instead of unreliable hidden or clipped Illustrator geometry.

Second, the ExtendScript runtime itself. Adobe's ES3 environment lacks much of the modern JavaScript platform, so I built the infrastructure I wanted to have.

The work includes native acceleration, differential fuzzing, browser conformance tests, binary packaging, reverse engineering, and live-engine benchmarking.

Software has been part of my life since childhood. Later, I began applying the same systems mindset to physical processes.

At Carboxyl Manufacturing I worked on phytocannabinoid crystallization, manufacturing R&D, instrumentation, and process optimization.

I developed a Python and Raspberry Pi crystallization incubator with closed-loop thermal control, environmental sensing, and process telemetry.

That work contributed to a reported 44% improvement in process efficiency across the broader engineering program.

A long-running investigation into freeze drying expanded into:

thermodynamics · vacuum physics · gas conduction · heat transfer · Pirani sensing · firmware · refrigeration · control systems

I reverse-engineered commercial firmware and developed models around pressure-dependent thermal transport inside the vacuum chamber.

The key insight was simple: residual chamber gas is not merely something to remove. In the relevant pressure regime, it is part of the heat-transfer system.

CIDARTHA
High-performance CIDR membership infrastructure using native C, compiled data planes, adaptive representations, packed operations, and SIMD-assisted search.

Project ANVIL
Experimental lossless-compression research focused on the compression, encode, decode, and memory Pareto frontier.

One rule drives Project ANVIL:

A ratio win is not a codec win.

Failed mechanisms stay in the research record instead of being rewritten as successes.

I am deliberate about semantics, architecture, and evidence.

A vague requirement usually becomes a set of explicit invariants before I implement it. A performance claim becomes a benchmark. A surprising behavior becomes an experiment. A failed idea becomes part of the research record.

flowchart LR
    A["Baseline"] --> B["Profile"]
    B --> C["Hypothesis"]
    C --> D["Change"]
    D --> E["Benchmark"]
    E --> F{"Better?"}
    F -->|No| B
    F -->|Yes| G["Stress"]
    G --> H["Verify"]

I usually look for architectural wins before micro-optimizations:

• remove work instead of making unnecessary work faster
• make recomputation incremental
• encode invariants directly in the data structure
• bound concurrency and fanout
• defer work until it is actually needed
• benchmark the real bottleneck
• test under contention
• measure secondary costs
• preserve negative results so they are not rediscovered

Languages
TypeScript JavaScript Python C C++ Java SQL ExtendScript

Systems
Electron Node.js Bun SQLite IPC HTTP SSE MCP CDP GitHub Actions

Graphics & documents
SVG Canvas PDF PPTX DOM/CSSOM Adobe Illustrator vector geometry

Scientific
crystallization thermodynamics vacuum systems heat transfer process control instrumentation