Léonard Noth
ENFRDE

I design systems,build products, and makecomplicated technologyunderstandable.

I design software, support the people who build it, and pass the craft on, from Fribourg in Switzerland. Trained in data science and guided by product, I turn research and teaching questions into concrete tools that are genuinely used.

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 reasons people call me — each shown through a concrete project and the decision it took.

01

Build

I turn an idea into a product used by real people, from the first line of code to deployment.

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 and full-time engineer, two products on one codebase

At YEPA I am CTO and 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 complexity into concrete tools, then check that they genuinely meet the need.

HEIA-FRIn detail

Lecturer at 20%, interaction design and semester projects

Most of the people I teach 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 point was not piling up features, but making the right decisions.

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 who support 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 — the best of the five model families compared — 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” and too often leaves it there. It rarely tells you for whom, or whether the thing described has already happened. A single article can be favorable for one company and worrying for another, and can mix an event from last year with a forecast for next quarter. Reducing that complexity to a single 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, who 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 was born from a project that went better when I followed it — or worse when I ignored it. Since each habit implies a concrete gesture, it's noted right underneath.

Approach
  1. 01

    Numbers I can defend

    A number I'd defend to my thesis 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 real skill is recognising the situations where something else serves better.

    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's essential, invisible everywhere else.

    A shopkeeper should only ever see their customers, 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 the why can make the next decision 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 already the start of building it.

I teach human-computer interaction and supervise semester projects at HEIA-FR, at roughly 20%, alongside my other work.

Teaching
What I explain to them
  • A good system solves a real problem.
  • Build it in pieces, because you will end up replacing one of them.
  • Every decision must have a reason you can say out loud.
  • Ask. Someone else's experience is the most direct shortcut 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. Full-time engineer as well as CTO, so the architecture is my responsibility.
  • 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.