Linh Le · senior full-stack engineer · end to end, from server to screen

Thirteen years, every layer.

I can be the one engineer who takes a feature from LoRaWAN radio firmware and bare-metal Linux, through AWS pipelines and Elasticsearch read layers, to the Vue and React dashboards people use every day. Remote-first and written-first. These days that increasingly means AI infrastructure clients run on their own hardware.

Stack · TypeScript · JavaScript · Node.js · React · React Native · Vue 3 · Angular · Python · Go · Rust · C · C++ · Zig · AWS (IoT Core, Lambda, SQS, SNS) · Azure · SQL · Elasticsearch · Linux/Unix · LoRaWAN/IoT

Talk about a contract

Sofia-based · remote full-time or B2B contract linh@lelinh.dev CV (PDF)

01 · Product

When. — live, paid, and mine.

When. is a private period tracker that lives in the calendar you already check — Google, Notion, or CalDAV — instead of being one more app to open. Log the day a period starts; it learns the cycle and writes each predicted phase back as calendar events. €4/mo after a 14-day trial. Co-created with Anna, and run end to end: product, infrastructure, billing, support.

The constraint came before the features: a period tracker shouldn't hold your cycle. So this one doesn't. The calendar you already own is the only place that data lives, which means there is no cycle database to design, to secure, or to breach. The cost is that the calendar API is the storage layer — anything the product remembers has to be expressible as an event, and every feature has to earn its way back through that constraint.

02 · Track record

Where the thirteen years went.

The full history →

03 · Recent

AI infrastructure clients run on their own hardware.

A growing share of my contract work is designing and running AI infrastructure for clients who want it in-house: self-hosted model inference and training on hardware they control, plus the automated agent infrastructure around it. It is reliability and cost engineering on a newer kind of dependency — several providers behind one interface so a rate limit or an outage doesn't kill a running job, work routed per task so the expensive model is only used where it earns its cost, and automated checking of what comes back before it is trusted. I run the same stack on my own hardware, which is where I prove it first.

Using models seriously in my own work stopped being an API call and became something to operate: long jobs die when a provider rate-limits, cost scales with the work rather than its value, and some context shouldn't leave my machines at all. So I built for that — an endpoint I own, a fleet of providers behind one interface, and budgets that put cheap work on cheap models.

LayerThe problem it solvesWhat it is
Own endpointWork that shouldn't be metered per token, or shouldn't leave my infrastructure.llm.lelinh.dev · 35B · 93k ctx
Provider fleetOne vendor is one price, one rate limit, and one outage.8 providers · one interface
Budgets & routingThe expensive model is waste on most work; the cheap one is waste on the rest.per-model context + sampling
VerificationThe real failure isn't a model that stops — it's one reporting work it didn't do.claims audited vs. files on disk
SupervisionLong jobs die quietly and lose everything since the last checkpoint.systemd · relaunch · rolling commit

The verification row is the one I'd defend hardest — everything above it is cost and uptime engineering, but that one is correctness engineering, and it's what changed the output quality. The whole loop is deliberately non-durable: nothing enabled at boot, everything started on demand. A fleet that runs when I'm not watching is a bill, not a tool.

It drives real work rather than demos — currently a Vulkan-rendered 3D editor and runtime in Zig. See the work →

04 · Next

Available for contract and full-time remote.

If you have a system that has to hold up — telemetry at volume, an AWS bill that stopped making sense, or a platform that needs owning end to end rather than handing across a fence — that is the work I want.

linh@lelinh.dev