I build platforms that make messy systems programmable.
Dozens of third-party APIs that agree on nothing, behind one interface that holds up in production. I have spent eight years doing that to carrier and logistics systems, which are the worst version of the problem I have found.
Product engineer at JTL-Software, leading Karrio inside it.
Logistics is about to be run by software rather than by people clicking through dashboards. Carrier selection, rate negotiation, exception handling, customs decisions. All of it becomes something a machine can address directly. The systems that matter will be the ones with clean, programmable surfaces. Most of this industry is still shipping dashboards.
Integration architecture
Third-party systems are hostile by default. Different auth, different error semantics, different ideas of what a valid address is, and documentation describing a version nobody shipped. The work is a data model that survives all of them and an adapter layer that makes the next one cheap. In Karrio that took a new carrier from a quarter of engineering down to days.
Karrio is the third time I have built this. Multi-vendor instrument APIs for hardness testing at Clemex, a vendor-agnostic quantum computing cloud at Resonance, then carriers.
Designing for extension
Anything I build gets used in ways I did not plan for. Karrio's plugin SDK means someone I have never met adds a carrier I have never heard of, and it has to work without me reviewing it. That single constraint settles most of the design upstream of it: how strict the data model can be, what the adapter contract is allowed to promise, where you leave an escape hatch and where you refuse one. Get it wrong and you either block people or spend your life repairing their integrations.
Open core, in practice
Karrio runs as open core: an LGPL community edition, and a commercial tier for what an operator needs at scale. The licence was the easy part. The real question is whether someone can build something serious on the open edition without ever talking to you, because if they cannot, no community forms, and a commercial tier with no community upstream of it has nowhere to sell.
Leading the work
I ran my own project for years before I was responsible for anyone else's work. By the time I was setting a technical bar for other people, I had been living with the consequences of my own calls in production for a long time. That is most of what I bring to hiring and to architecture review.
Karrio
Open-source shipping platform. API-first and self-hostable.
Every company that ships a physical product rebuilds the same carrier integration layer. UPS, DHL, FedEx, USPS, Canada Post and the regional carriers each expose a different API, a different rate model, a different label format and a different idea of what a valid address is. Teams lose months to it, then maintain it forever, and none of that work differentiates them.
One carrier-agnostic data model, with every carrier pushed behind a plugin SDK rather than into a switch statement that grows without end. Rating, labels, tracking, customs documents and fulfillment orchestration sit behind a single interface, with REST and GraphQL generated over the same core. Adding a carrier became something a team outside the project could do themselves.
The community edition is LGPL and useful on its own, self-hostable with no vendor in the path. The commercial tier covers multi-tenancy, rate limiting and orchestration: what an operator needs at scale and a single developer does not. That line is the business, and it is the decision I spent the most time on.
Production infrastructure for platforms, retailers and logistics teams, with a contributor community extending it into markets I will never see. In 2025 Karrio and I joined JTL-Software, where it runs as the shipping layer inside an established European e-commerce software business.
-
2025 – now
Product Engineer, Shipping Platform · JTL-Software
I lead Karrio's direction inside JTL: roadmap, architecture, and the question of how an open-source project fits a commercial ERP and fulfillment stack.
Two operating models that rarely mix. An open-source project has an external contributor community and its own norms. An enterprise software business has a release cadence and support obligations. Making both work at once is most of the job.
-
2020 – 2026
Founder & CEO · Karrio
Built the platform, the plugin architecture and the open-core business around it. Full write-up above.
-
2024 – 2026
Founding Engineer · Teleship
First engineer on a cross-border shipping platform. Owned the platform architecture, the engineering standards behind it, and the technical bar we hired against.
Cross-border logistics fails on edge cases, so the architecture has to make edge cases cheap. That drove most of what I built and all of what I refused to build. I carried the carrier integration patterns proven in Karrio straight into production there, which cut most of the usual discovery cycle on customs, rating and multi-carrier behaviour.
-
2022 – 2024
Senior Full-Stack Developer · Resonance
Owned backend and infrastructure for market intelligence platforms across quantum computing, space, climate and AI, and built prototypes for adjacent businesses the company was exploring.
Two of those reached MVP: an early system for AI-generated, industry-specific news summaries, and a vendor-agnostic quantum computing cloud platform. Both were built while GPT-3 and GPT-4 were still new.
Migrated the platform onto Amazon EKS, which took fetch and search throughput across quantum industry data up by roughly 100x.
-
2018 – 2020
Full Stack & Infrastructure Developer · Clemex Technologies
Python backend and the CI/CD infrastructure under it, both at the same time for most of my two years there rather than one after the other.
Sat between the engineering and ML teams and built the integration layer that bundled trained models into releases, with TensorFlow models loaded at runtime for automated hardness testing.
Designed the hardness testing APIs to speak to instruments from multiple vendors rather than to one. The first time I built an abstraction over hardware nobody had agreed on a standard for.
-
2014 – 2018
Software Developer · VuWall
Four years across the stack on video wall control systems, ending up as the frontend lead for the team.
Built the component library from scratch, and the first frontend application for VuWall TRx.
Notes
Nothing published here yet. What I intend to write about: carrier integration as an architectural problem, where to draw the line in an open-core business, and what happens to logistics when software is the operator rather than the interface.
Open to a small number of conversations.
Technical leadership roles, and advisory work with teams building logistics or commerce infrastructure. Most useful to teams somewhere between three and twelve months into building carrier integrations in-house.