I build system-level tools for Windows — the ones that dig into APIs nobody documents, solve problems that "should just work", and don't ask you to click through six settings screens to do one simple thing.
Most software is a wrapper around a wrapper around a bad API decision from 2009. I try to avoid that whenever the platform allows it.
I work close to the system layer — COM interfaces, Windows audio internals, native event pipelines, low-level device orchestration, and the parts of the platform most applications never touch directly.
Every product starts from a real operational problem, not a feature checklist. I build tools that should probably exist natively in Windows, but don't.
The architecture is usually the same: a native C++ core responsible for the system layer and performance-critical logic, with a thin orchestration/UI layer on top when the platform needs one.
IPolicyConfigVista via vtable probing (undocumented COM interface Microsoft
won't acknowledge). One hotkey, all devices move. Games auto-switch on launch,
auto-restore on exit. The kind of thing Windows should have shipped with in 2009.
No cargo-culting. Every tool earns its place.
If something on Windows is broken and it shouldn't be — that's my kind of project. Custom system tools, Windows internals, anything that requires going below the surface.