Léonard Noth
ENFRDE

I design systems,build products, and makecomplicated technologyunderstandable.

I build software, lead the people building it, and teach it, from Fribourg in Switzerland. Data science by training, product by instinct: I turn research and teaching questions into things people actually use.

Léonard Noth
  1. 01Problem
  2. 02Understand
  3. 03Design
  4. 04Build
  5. 05Explain
  6. iterate: Build → Understand · learn: Explain → Problem

What I actually do

Four things people call me for. Each one with the project where it actually happened, and the decision it took.

01

Build

I take an idea from nothing to running in front of real users, and I stay in the code while I do it.

FlowerCamIn detail

Lead developer, 2021 to 2023, three shops in Fribourg

FlowerCam let a customer at home drive a robot around a real shop, and I wrote the video server that made that call possible.

A shop has customers in it, and the face of someone who never agreed to be filmed does not go out over the internet. Blurring every face that isn't staff was the legal condition for running at all, and the moment software has to look at the pixels, a direct browser-to-robot connection is impossible by definition.

So I wrote our own streaming server: a full WebRTC peer on both sides of the call, decoding every frame, asking a face service which faces belong to the shop's staff, blurring the rest, and re-encoding. It costs over 100 ms per frame, and it is the reason the robot could be driven through a florist, a furniture shop and a relaxation retailer with real customers in the aisles.

Read the case study
02

Structure

I design systems that are still understandable when someone else opens them a year later.

SAFEIn detail

Master's thesis, 2024, graded 6 out of 6

SAFE reads financial news and works out when an event sits in time, and nobody agrees on what “recent” means.

For a day trader the present lasts hours. For a pension fund it lasts a quarter. If that boundary is learned by the model, serving both audiences means relabelling the corpus and retraining it.

So the class boundaries live in a configuration file, and explicit dates never reach the network at all: a rule-based tagger handles them, because “last year” is arithmetic against a moving today and weights cannot hold that. Changing what present means became a one-line edit. It is the decision from that thesis I defend most willingly.

Read the case study
03

Decide

I set the direction, hand out the work, and own the call when the answers conflict.

YEPA, KOCO PredictIn detail

CTO, only full-time engineer, two products on one codebase

At YEPA I am the only full-time engineer, so every disagreement between the research side, the freelancers and the product lands on my desk.

Two pedagogy researchers describe what the method needs, freelancers and students build parts of it, and I brief them, review what comes back and settle the architecture. A good share of the job is telling the research side when what they are asking for isn't what they mean.

The clearest case was the classifier. Sorting an interview fragment into the seven concepts of the pedagogical ontology looked like a job for the frontier models, so we tested them properly and they plateaued. A small model trained on our own labelled corpus reached 94% on 350 expert-labelled samples, twelve points clear, and that is what ships, inside 23 infrastructure stacks with a deploy gate that refuses to replace a live database table.

Deciding also means going back on the brief. On KOCO Predict we had agreed an hourly forecast; at that resolution 98% of the series was interpolation I had drawn myself. I moved it to daily, where a quarter of the points are real weighings, and defended a model that looks less impressive on paper and gives numbers a dispatcher can act on.

Read the case study
04

Teach

I turn something complicated into something a person can hold, then check that they can.

HEIA-FRIn detail

Lecturer at 20%, interaction design and semester projects

Most of my students arrive unable to build a website, and leave able to build one that works and to prove that it does.

In the human-computer interaction course the deliverable isn't a page that looks finished. It is a site people can actually use, with the means to judge it: code quality, user testing, interface evaluation.

On the semester project I carry the data and AI side. Teams learn to move data between a data team, a backend and a frontend, and to build a first model from nothing: find the data, understand it, sort it, work out which model the problem is really asking for. Twenty students trying your explanation at once is the fastest way to find out which part of it was never true.

Featured work

Four projects where the interesting part was the decision, not the feature list.

index →

YEPA

2025–present

Turning lived experience into a readable mapping

Problem
Explicitation interviews worked. The technique gets someone to describe what they actually did, not what they think they should say, but it needed a trained expert in the room. One interview ran an hour to ninety minutes, and turning it into a formal mapping of someone's competences took another five to six hours of expert work afterwards. That put the method out of reach of the people who needed it most: career changers, job seekers, and the counsellors trying to help them at scale.
Role
CTO & lead engineer
Decision
Train a specialised classifier instead of prompting a frontier model, after proving the frontier models plateaued
Outcome
An interview anyone can take, in 15 minutes to an hour instead of 90, producing a mapping in five to six minutes instead of five to six hours. Across three rounds of testing with 36 participants, every respondent agreed the interview left them enough time to think, and the people with no prior chatbot experience gave it the highest recommendation of anyone. It all feeds two products built from one codebase: yepa.solutions for individuals, and yepa.expert, invitation-only for researchers, with code-gated campaigns, anonymous respondents and group-level analysis.

KOCO Predict

2023–2025

Forecasting a bin so trucks stop driving to empty ones

Problem
KOCO's existing forecast was an adaptive linear regression: average the fill rate between two collections and extrapolate. It works, but it only ever sees data from collection days, a handful of points a week. The company wanted to know whether eighteen months of sparse weighings could support something better.
Role
Research engineer
Decision
Lower the resolution from hourly to daily, because at hourly, 98% of the data was a line I had drawn myself
Outcome
Prophet cut mean absolute error from the incumbent's 75.0 kg to 48.04 kg on real collection days, and MAPE from 40.4% to 19.8%. Both partners rated the project 1 of 4 (very successful) in the final report to Innosuisse.

SAFE

2024

Reading financial news three questions at a time

Problem
Off-the-shelf financial sentiment tells you a headline is negative. It rarely tells you negative about whom, or whether the thing described has already happened. A single article can be optimistic about one company and grim about another, and can mix an event from last year with a forecast for next quarter. Treating that as one score throws away most of the signal.
Role
Sole author
Decision
Put the temporal class boundaries in a configuration file rather than in the model's weights
Outcome
Graded 6 out of 6. Three separable questions answered per sentence fragment, aggregated per company and per time window, with named emotion pairs instead of a forced single winner.

FlowerCam

2021–2023

A robot you can drive from your sofa

Problem
The idea came from a florist. Adrien Hertig noticed his customers had stopped coming into town and were ordering online instead, and thought it would be good if they could still be walked around the shop by one of his staff. Then COVID closed the shops entirely. The question became whether a remote customer could genuinely browse a real shop from a phone: see what they wanted to see, be served by a person.
Role
Lead developer, technical lead
Decision
Give up on peer-to-peer and make our own server a real WebRTC peer on both sides, because we had to see the pixels
Outcome
Ran in three partner shops in Fribourg (a florist, a furniture shop and a relaxation retailer) with a mobile app on both stores and real-time face blurring that let the robot operate in a shop with customers in it.

Six habits, and the projects that taught them.

Not values on a wall. Each one is here because a project went better when I followed it, or worse when I didn't. Each one also has a price, so the price is written underneath.

Approach
  1. 01

    Measure what matters

    A number I'd defend to a supervisor, or no number at all.

    YEPA's classifier is scored on 350 samples labelled by the pedagogy researchers, not on a demo that went well.

    YEPA · KOCO Predict

  2. 02

    Know when an LLM is the wrong tool

    Large models are powerful and non-deterministic. The skill is telling which problem is which.

    Same product, same week: a schema-bound LLM won one job outright and lost the next one by twelve points.

    YEPA · Atelier

  3. 03

    Keep the complexity underneath

    Rigorous where it counts, invisible where it doesn't.

    A florist should only ever see her customer, never the face recognition running behind the stream.

    FlowerCam · YEPA

  4. 04

    Prototype, then optimise

    People discuss a product they can see. They negotiate a concept they can't.

    Seven people answering eight questions changed Dutine more than a month of thinking had.

    YEPA · Dutine

  5. 05

    Explain the decision, not just the result

    A client who understands why can make the next trade-off with you.

    Dropping KOCO Predict from hourly to daily made the model look worse on paper and the numbers trustworthy in practice.

    YEPA · KOCO Predict

  6. 06

    Design for whoever maintains it

    Written budgets, real boundaries, shared code where two products overlap.

    A deploy gate that reads the infrastructure diff and refuses to replace a live database table.

    YEPA · SAFE

teaching

Understanding something is part of building it.

I teach human-computer interaction and semester projects at HEIA-FR, at roughly 20% alongside the rest.

Teaching
What I tell them
  • A good system solves a real problem.
  • Build it in pieces, because you will end up replacing one of them.
  • Every decision needs a reason you can say out loud.
  • Ask. Someone else's experience is the cheapest thing you will ever get.
  • Leave the code better than you found it.

Technical toolbox

Products I build with

  • TypeScript
  • React
  • Next.js
  • Tailwind
  • Vue
  • Svelte
  • Flutter
  • Python
  • PHP

Systems I operate

  • AWS
  • CDK
  • Lambda
  • DynamoDB
  • Step Functions
  • AppSync
  • Docker
  • Redis
  • SQL

AI systems I design

  • PyTorch
  • Transformers
  • Embeddings
  • LLM pipelines
  • scikit-learn
  • spaCy
  • Prophet

Decisions I lead

  • Architecture
  • Technical strategy
  • Delivery planning
  • Directing freelancers
  • Teaching

Currently

  • CTOYEPA. The only full-time engineer, so the architecture is mine to own.
  • LecturerHEIA-FR, human–computer interaction and semester projects, now at 20%.
  • BuildingAtelier, a suite that helps content creators go from an idea to an edited video, ready to post.