Fabio Keller · platform engineering
I build theinfrastructureAI runs on.
Seven years of AWS and Kubernetes platforms, from document AI to warehouse robots.
It started with music.
I studied music and played for years. Sound was the first system I learned to build, and a live set is just production with worse uptime.
Then I built the instruments.
At university I went from playing to making: hardware synths, electronic music, and a granular synthesizer I wrote from scratch in C++. That project taught me to program.
My first code ran on a warehouse floor.
First real job: an e-commerce platform building software and hardware both. On the floor I built a put-to-light picking cart, 36 LED bins on a Raspberry Pi. Picking got 50% faster.
Then I went underneath.
To make all of it reliable I went deep on infrastructure: AWS, CI/CD, Kubernetes. For two years I taught it too, cloud engineering to career changers, 20 to 30 at a time.
Which is how I got here.
Today I architect event-driven infrastructure for AI products. Same instinct as the synth: pick the machine that should exist, then build it.
dwg FK-2026-03 · case 01 · ExB Labs
Case Study 01Paperwork,
at scale.
Still read by hand.
Freight in Germany moves on paperwork. Tens of thousands of documents a day that someone has to read, understand, and type into other systems. Slow, expensive, and wrong often enough to hurt.
Four ways in.
Documents arrive however the customer works: uploaded in the product, dropped into S3, mailed to an ingress address, or fed straight from their own systems.
Isolated by default.
Agents read untrusted input and act on it, so the platform assumes they will misbehave. Every customer solution runs its own agents in its own Kubernetes namespace. One bad document can never touch another customer's data.
Agents that read.
Pydantic AI calling Gemini reads and extracts. Microservices talk over Redis queues, so no service waits on another and a spike in one customer's volume stays their spike. EKS Auto Mode sizes the cluster itself.
Seventy percent, untouched.
Customers approve results in the product, but documents read with high confidence, around 70% of the volume, flow straight through: emails sent, internal systems updated via API.
dwg FK-2026-04 · case 02
Case Study 02Revenue,
by feel.
Scattered on purpose.
Resource planning in Float. Customer lifecycle in HubSpot. Contracts in spreadsheets. Product usage locked inside the product itself. No two of them agreed on anything.
Airbyte pulls it together.
A nightly sync from all four, including the product's usage through a custom Airbyte source I wrote against our own API. Everything lands raw in BigQuery, untouched.
Everything, in one place.
Raw tables from every source, queryable together for the first time. The whole stack self-hosted on our Kubernetes cluster, BigQuery the one exception.
dbt does the thinking.
dbt models the raw tables into the entities the business actually reasons about: customers, contracts, utilization, margin. The dbt image is built by CI and runs as a Kubernetes cron, versioned like any other service.
Margins with your coffee.
Every KPI the company runs on, served in Metabase and refreshed every morning, on dashboards anyone can open. Margins went from computed-by-hand-quarterly to a number you glance at before standup.
dwg FK-2026-05 · case 03 · BerryBase
Picking,
on foot.
The slow way.
An e-commerce warehouse picked orders one at a time: one picker, one order, one walk through the aisles. The fix wasn't software alone. It was a machine.
One walk, 36 orders.
I planned and built a put-to-light trolley: a cart carrying 36 order boxes, each slot wired with LED strips. At every storage location the lights show which orders need that item, and how many. One walk now serves 36.
A Pi per trolley.
Each trolley runs on a Raspberry Pi. On it, a Python app I wrote in Tkinter drives the touchscreen picking UI, talking to the cloud ERP through a REST API I extended with a PHP plugin. An arcade button advances the pick, an NFC reader handles Yubikey login, and a barcode scanner kills wrong-item errors before they ship. Every trolley ships its logs to S3.
Flashed, on demand.
The part I'd show another engineer: each Pi boots a custom Linux image, stripped to the processes the trolley needs, built by a pipeline that produces a flashable image on demand. Fleet provisioning is a download, not an evening of setup.
Picking, up 50%.
Measured after rollout across a fleet of half a dozen trolleys: picking effectiveness up almost 50%. One walk, 36 orders, lit by LEDs and run by a Raspberry Pi.
Let'sbuildit.
Reply within 24 hours. Tell me what you're building and where it's stuck.