A place to follow the question further
Professional production work taught me to care about operators, evidence, lifecycle, and the physical environment around software. Independent projects give me room to carry those concerns into domains where the shape of the problem is completely different.
One project decodes a live rail feed. Another joins embedded plant sensors to a web application. Native macOS tools run language models locally or prepare approval-gated repository work. Private systems model dental-practice operations, caregiver health workflows, travel planning, and company-scale orchestration. Simulations make semiconductor economics, territorial strategy, and city systems tangible.
Five active directions
Transit feeds, embedded sensors, device configuration, OPC UA, persistent readings, and interfaces that carry physical-system context.
MLX inference, native agents, orchestration, plans, handoffs, tools, risk levels, and human approval before consequential actions.
Dental operations and caregiver health software where detailed domain rules, safety, and complete workflows shape the architecture.
Chip companies, territorial growth, city finance, population, happiness, and other systems made understandable through interactive state.
Computer vision, graduate face-recognition experiments, investing research, financial scenarios, valuation, and document processing.
The archive matters too
The work did not begin with the current flagships. Earlier repositories include a Python assembler and simulator for a minimal RISC architecture, embedded software for a robotic crop weeder, a COVID-19 data visualization, Android applications, health-savings analysis, financial calculators, and smaller utilities.
Not every repository deserves equal prominence. Empty scaffolds, forks, hello-world projects, and isolated labs remain on GitHub without being turned into portfolio claims. The software archive instead preserves the serious earlier work that shows how the practice developed.
Build enough of the system to understand the operating problem, then preserve what the experiment taught.
The recurring operating pattern
Underneath the domain differences, the projects repeatedly follow the same sequence: ingest a difficult input, structure it into explicit state, validate the transformation, explain what matters, and provide the operator with a useful next action.
The detailed project pages make that pattern inspectable. Public repositories link to source. Private and local work is described without pretending that the code is available. Roadmap items are distinguished from implemented behavior, and research output is not presented as advice.