I'm a product engineer. What I like is the whole loop: sitting with the people who'll use a thing, deciding what it should be, then building it down to whatever layer the problem turns out to live at.
ShipMonk has been the last four years of that. I lead the engineering team for the B2B fulfillment domain, the wholesale side of a company that had only ever done D2C. I was one of the first engineers in the domain; it's now a ten-person team owning the platform the wholesale business runs on, and I lead the design decisions behind the B2B processes and their implementation.
The work I'm proudest of there is a warehouse-management-system migration: integrating an acquired operation whose processes lived only in people's heads, holding customers through a year-long bridged state, and landing them on the full platform without breaking their experience. Most of that job was process discovery and stakeholder alignment rather than engineering, and it's the half I'd least want to give up. It meant deep integration between two systems, which pulled in the OMS/WMS split inside ShipMonk and a move to an eventual-consistency model for parts of the application.
The other half is the systems work: performance across the whole platform for B2B orders, which run orders of magnitude larger than anything it was originally built for. Splitting work across consumers, getting the locking right so the parallelism didn't introduce races, and moving user-facing actions out of the request cycle into asynchronous jobs.
That work also left me debugging ZPL (the language thermal printers speak) more or less daily, with tooling that amounted to one twenty-year-old incumbent with page-count caps and no self-serve signup. So I built zpl.tools: a hand-written ZPL parser and render engine in Rust, compiled native for the API and to WebAssembly for the browser preview and the desktop app. Usage-based pricing, an API key in minutes, no sales call. Speed is the product position. It benchmarks 2 to 5.5× faster than the incumbent on a published, reproducible methodology. People at ShipMonk use it daily.
It's also where I learned Rust properly, not from a tutorial but from having to make a parser fast and a renderer correct, then owning everything underneath it.
Before ShipMonk I joined NFCtron just after its seed round as an early engineer in a team of three; it grew into a company doing over a billion CZK in annual turnover. I worked on everything from the raw NFC memory layout to the Kubernetes cluster setup. I primarily owned the B2B application providing the business insights to our customers. The company's core product was a distributed, offline-first NFC payment system.
I studied Open Informatics at CTU FEE, BSc and MSc, both with honours. The subjects that stuck were the low-level ones. Computer architecture in assembler, operating systems, caches, and a performance course graded on measured runtime rather than on whether the code merely worked. That course is where I first saw how much of a program's speed is decided by how it treats memory, and I've read systems that way ever since. The same instinct shows up in the hardware projects on this site: a custom PCB in KiCad, an RF chip chosen off its datasheet, an analog amplification and ADC stage.
The other subject I got the most out of was the psychology of UX, which sat at the far end of the same degree. That pairing is the honest picture of me. I like knowing what the machine does with a cache line, and I like sitting with the person who has to use the thing and working out why they hesitate. Products fail on both sides, and I've never wanted to specialise into only one of them.
C is the language I like most and the one I've never shipped. Everything I built outside school had a business on the other end of it, and C sits a long way from that; at the scale I was working at, it also offers too many ways to be quietly wrong. So it stayed a way of thinking rather than a tool I reach for: what the machine actually does with a structure, what a memory access costs, where the copy you didn't write happens. That's the lens I brought to Rust, and most of why the performance work at ShipMonk and on zpl.tools went the way it did.
On the stack, honestly. Day to day it's PHP (Symfony) and TypeScript (Nest.js) with SQL underneath. The systems work lives elsewhere: Rust on zpl.tools, C and C++ before it. Python, Docker and Kubernetes are in reach. Which language matters less to me than whether I get to own the thing end to end.
I'm based in Prague and work remotely.