Work
One application you can download, one repository of the site you are reading, and the engineering I do for a living. They are kept apart here, because they are not the same kind of evidence.
Public projects
Two repositories, both MIT
-
01
v1.4.0 · macOS 13+ · Windows 10/11 · SwiftUI + C# · MIT · released 30 Oct 2026
Keeps one proxy profile for each app it can start — ChatGPT, Antigravity App, Antigravity IDE — and passes that endpoint in at launch, with no TUN device and no change to the system proxy or DNS. Settings belong to one process tree instead of the machine, and the interface says so.
The interesting part was not the feature. It was the diagnostics and the packaging: four observations that each state what they did not establish, a Windows edition that shares behaviour but not code, and a release that refuses to publish until both builds pass.
Project page and downloads Official site Source Download 1.4.0
-
02
2026 · HTML · CSS · no build step · GitHub Pages
Hand-written HTML and one stylesheet, with a self-hosted typeface subset and no framework. It is here as a public example of the smaller end of the same habit: keep the system small enough that it can be explained, and let the explanation be checkable.
Engineering experience
Practice, not portfolio
These are the areas I have worked in professionally. They are described as practice rather than as projects, because the code is not mine to publish: no employer, client, internal system or dataset is named here, and nothing below is presented as open source.
What can be said honestly is the shape of the problem, the part I owned, and what I would expect to be held responsible for afterwards.
- Backend & microservices
- Java and Spring Boot services, the contracts between them, and the failure paths that only appear once two services disagree about what a field means. A lot of that work is integration where the other side of the interface is someone else’s and cannot be changed.
- Data engineering & platforms
- Collection, processing and quality checks, plus the modelling that keeps a number explainable months after it was produced. The pipelines I care about are the ones that fail visibly rather than produce plausible wrong data.
- Full-stack delivery
- React interfaces built against an API I also own, so the awkward parts of the data model surface in the interface instead of in a ticket three weeks later.
- AI-assisted engineering
- Coding agents used for review-heavy work: reading an unfamiliar codebase, drafting a change, running the checks. The part that matters is what the review step has to become, not what the model can generate.
- Cross-platform delivery
- Desktop tools built natively for macOS and Windows — SwiftUI and AppKit on one side, C# and WPF on the other — including packaging, signing limits and the release checks that decide whether something is shippable.
What is public, exactly
As of 30 Oct 2026
- Repositories
- 2 public — the launcher and this site
- Latest release
- v1.4.0 · 30 Oct 2026
- Launcher runs on
- macOS 13+ (Apple Silicon) · Windows 10 22H2 / 11 (x64)
- Languages
- Swift · C# · HTML/CSS
- License
- MIT, both repositories
- Distribution
- GitHub Releases — DMG, Windows setup, source ZIP, SHA256SUMS.txt
- Tests
- Core, integration, UI and installer checks; run locally before publishing
- Signing
- Ad-hoc on macOS, not notarised; the Windows installer is unsigned
No download counts, adoption numbers or testimonials appear on this page, because there is no way to verify them from here. Releases, commits, issues and the checks above are the only claims the site makes about the work, and each one can be inspected.