const developer = "Jonathan Frecker";
I've spent ten years making systems talk to each other — from financial platforms and in-house C# applications to HL7 feeds, DICOM workflows, and clinical APIs. Now I'm applying that foundation as I transition into a full-time software engineering role.
// _about.md — who I am and how I got here
I've been working in technology for over ten years across two industries. I started on the ground floor of a stockbroking firm — Messenger, then IT Support, then Junior Programmer — writing C# applications, managing SQL servers, building SSRS reports, and eventually working independently as the sole programmer after our senior developer left. That environment taught me how to ship under pressure with real business consequences.
From there I moved into healthcare IT, spending the last five years delivering and supporting HL7 and DICOM integrations across RIS and PACS environments. I now work at the intersection of clinical operations and technical systems — where data reliability isn't optional and multi-vendor troubleshooting is a daily discipline.
My current focus is moving fully into software engineering and systems architecture — building with C# and .NET, running a self-hosted homelab on Proxmox, and working toward cloud-native deployments on Azure. A few things I work with regularly:
// _projects.cs — things I've built
A production C# WinForms application built and owned end-to-end at E. L & C Baillieu — automating ETL, SQL-driven SSRS reporting, and email delivery to ~2,000 clients. First time owning a business-critical system solo, under real production pressure, after the senior developer departed.
A self-hosted Proxmox cluster built and operated as a personal cloud platform — real infrastructure, real constraints, and zero exposed ports to the public internet.
A self-hosted AI environment pairing a chat/dev-assistant frontend with a locally-run open-weight LLM inference server on dedicated GPU hardware.
A self-hosted, tool-using AI agent that runs scheduled automation and answers questions over Telegram, powered by the homelab's own inference server.
Custom ESP32 firmware, written entirely in C# on .NET nanoFramework, that monitors homelab rack temperature and pushes real-time alerts.
End-to-end web presence and back-office hosting for a small business client — a live marketing site with a working quote pipeline, plus an isolated, zero-trust invoicing deployment.
A fully self-hosted, AI-accelerated NVR designed to replace a consumer cloud camera app — GPU-accelerated detection with no cloud subscription or data handling.
A C# library for parsing and validating HL7 v2.x messages, built to deepen .NET skills in a domain I know deeply. Handles ORM, ORU, and ADT message types, extracting structured segment data into typed objects for downstream processing.
A lightweight web dashboard for monitoring HL7 interface engine activity — parsing message counts and error rates by interface from log exports and surfacing them in a browser UI, built to replace manually combing through log files.
A C# desktop app that manages customers, generates invoices, and automates financial reporting for a small business — one of my first production systems, built in 2018 and still running today.
A read-only Model Context Protocol server built in .NET that connects Claude to a self-hosted documentation knowledge base — giving an AI assistant real tool-use to search, browse, and read pages, not just chat.
// _skills.json — { "what": "I work with" }
// how I think about engineering
I default to proven tools over whatever is new. Complexity has a carrying cost — in maintenance, onboarding, and failure modes. I reach for something newer only when the trade-off is explicit and worth making.
Most bugs are specification bugs. I spend time on the "why" before the "how" — reading the ticket, tracing the data, asking one more clarifying question. Code written against a clear problem statement is shorter and easier to delete.
Systems that can't explain their own behaviour are expensive to maintain. I treat logging, structured errors, and clear audit trails as first-class requirements — not afterthoughts. If something breaks at 2 AM, the logs should tell the story.
Long-lived branches accumulate risk. I prefer to merge small, demonstrably correct changes often. Each increment should leave the system in a better state than it found it — even if the full feature isn't there yet.
Ten years of working in finance and healthcare has made this instinctive. Silent data corruption is worse than a visible error. I validate at boundaries, fail loudly on unexpected input, and never assume the data upstream is clean.
Code is read far more than it is written. Names should say what a thing is, not how it works. Comments earn their place by explaining intent, not restating syntax. I write as though the person inheriting the code is smart, busy, and has no context.
// _experience.md — where I've been
// _contact.razor — let's build something
I'm currently mid-transition into a full-time developer role at Kailo Medical, so I'm not actively job hunting right now. That said, I'm always keen to talk shop, swap ideas, or hear about interesting work — in healthcare tech, cloud infrastructure, systems integration, or homelab builds. If that's you, or you just want to connect for down the line, feel free to reach out.