José Hurtado_
Twenty-four years of product design leaves a specific kind of residue. You start to see every piece of software through what it costs people when it fails: the spinner that never stops, the workflow that drops state mid-step, the AI agent that returns a confident wrong answer. After long enough, you stop trusting black boxes on principle.
Why Kernex
Most of my career has been spent in regulated, high-stakes environments: fintech workflows, healthcare dashboards, enterprise SaaS where a broken experience has a price measured in contracts, not just NPS scores. The AI agent tooling available when we started building Kernex was fast to prototype and slow to trust. Memory leaked under load. Cold starts were measured in seconds. The agent process had access to everything the host had access to. Nobody was building the infrastructure with the same care that product teams are expected to bring to the interface.
So we built Kernex in Rust. Not because it was fashionable. Because the requirements were load-bearing: OS-level sandboxing that the kernel enforces, not a proxy hopes to catch, deterministic memory that does not balloon under concurrent load, 12ms cold starts for scheduled workloads, and a type system that surfaces pipeline errors before deployment rather than mid-run. The same standard I would hold a production interface to, applied to the runtime underneath it.
Background
Senior Product Design Director. Twenty-four years across B2B SaaS, AI/ML product design, design systems, and accessibility. Past work includes Nestlé, Mastercard Services, CBX Agency, and products that shipped at scale in regulated industries. Based in Austin, TX.
Before Kernex, DXagency. Before that, two decades of watching what happens when the interface is polished and the infrastructure underneath it is not. At some point, the logical response is to fix the infrastructure.