Builder and problem solver, developer with a designer's eye.
I build small macOS tools that do one thing without a manual. By day I work inside a large C++ codebase and automate the work around it, so I have seen a great many ways an interface can fail the person using it. Curious by default, still learning something new most weeks.
Each one started as my own annoyance. The rule is the same every time: open it, do the thing, close it.
Drop a file in, drag one slider for target size or quality, get a smaller file out. It reads every file first, so you always know what you started with and what you got back.
Not released. Built for myself, shown here because the interface decisions are the point.
A menu-bar recorder built for long recordings: lectures, pairing sessions, user tests, QA repros. Measured 17 times smaller than QuickTime on the same screen content, so two hours fits in an email instead of on an external drive.
Still being built, and shown as such. It shares Squeeze's empty-state language and its rule about never hiding what a setting costs you.
Every control answers three questions at once: what it is, what it's set to right now, and what happens if you move it. Try the panel.
CRF 25 means nothing to most people, so the value carries a word next to it. The word is the setting; the number is for whoever wants it.
Under each control sits one sentence about what you give up. "Slower and warmer, but the smallest possible files" is a decision people can actually make.
"Sharper picture" on one side, "smaller file" on the other. Nobody has to guess which way is better.
Touch anything and the preset flips to Custom with a note on how to keep it. The app never quietly disagrees with its own labels.
My own training and coaching app. It generates workouts and pushes them straight into Zwift, reading what I actually did from Strava instead of asking me.
No signup, no waitlist yet. Ask me about it if you're curious.
Since October 2022 I've been at SOFHA GmbH in Berlin, part-time and hybrid, alongside my Informatik studies at Technische Universität Berlin. Most of my time goes into C++: reading, extending and maintaining a large, long-lived codebase. The hard part there is rarely writing new code. It is understanding why the existing code is the way it is before you touch it.
The rest is automation. I write PowerShell to take the repetitive work out of testing and release, and before that I built the test automation itself: parallel BDD suites in TypeScript with Cucumber and Selenium WebDriver, scenarios in Gherkin. Automating a process forces you to understand it completely, which is the part I actually enjoy.
I like problems I don't immediately know how to solve. Reading hundreds of failing scenarios taught me something design books don't: most bugs are really an interface that let someone do the wrong thing. That is the part I enjoy fixing, and it is why the apps above exist.
I automate testing and release workflows for a living, and I build macOS and web apps front to back, design included. You do not need a finished spec. Describe the problem, or the thing that quietly costs you an afternoon every week, and I will come back with something you can click.