Turning AI research into systems that ship.

The problem

Starting the day meant eight open tabs, each formatting its data differently and none of them saying what had actually changed.

What I built

• A FastAPI backend that normalises eight very different upstreams into one shape.
• A React + TypeScript frontend with TanStack Query for server state and Zustand for preferences.
• Data from Open-Meteo, CoinGecko, Frankfurter, Nager.Date, USGS, NASA EONET and Launch Library 2.
• A service worker that keeps the shell and last-good data available offline.
• Shipped as Docker Compose behind Nginx, with TLS terminated at the edge.

What I took from it

Stale-on-error caching made it reliable. Serving the last good value with an honest timestamp beats a wall of error cards.

The problem

A job posting leaves you guessing which gap actually matters. Finding out usually means handing your CV to someone else's AI service.

What I built

• Extracts the skills from both documents using local transformer embeddings.
• Sorts every skill into matched, missing, or nice-to-have — a decision, not a similarity score.
• Pulls a YouTube tutorial for each gap into a saved learning plan.
• Next.js frontend, Express backend, Tailwind interface.

What I took from it

Running inference on-device made it free and offline-capable, and meant the CV never leaves the machine.

The problem

Labelling policies by hand is slow and inconsistent between annotators. Most existing datasets are English-only, which excludes every policy that isn't.

What I built

• Scraping and segmentation turn raw policies into clean, classifiable passages.
• A fine-tuned multilingual BERT gives multi-label predictions with a confidence score.
• A Vue.js workspace pre-fills the model's suggestion, so the human only confirms or corrects.
• YAML export that drops straight into downstream research pipelines.

What I took from it

The interface was the leverage, not the model. Confirming a confident prediction is far faster than labelling from a blank slate.

The problem

A CV says what someone did, not whether they have actually shipped with Redis. A chatbot inventing details about my own career would be worse than no chatbot.

What I built

• A RAG pipeline: a curated corpus is embedded and searched by vector similarity.
• An open-source LLM served through Hugging Face rather than a proprietary hosted model.
• A Node.js and Express backend hardened with Helmet and a CORS policy.
• A React + TypeScript client with persistent history and visible error handling.

What I took from it

Grounding beats model size. Retrieval changed the failure mode from confidently wrong to honestly unsure.

The problem

Temporal grounding normally needs densely annotated video. That is expensive to produce and transfers poorly beyond the domain it was annotated in.

What I worked on

• Developed and evaluated training-free methods using pretrained vision-language models directly.
• Built the evaluation setup so approaches could be compared like-for-like.
• Supervised by Prof. Dr. Marcus Rohrbach at TU Darmstadt, as a 9-ECTS component of the programme.

What I took from it

Define the metric before you fall in love with the method, and treat a negative result as information. It also made me sceptical of benchmark numbers quoted without their protocol.

The problem

Healthcare software has high, repetitive read volume and a genuinely complicated data model. A validation bug there is a safety incident, not a bad experience.

What I built

• A Spring Boot microservice for patient management with JWT auth and role-based access.
• Redis caching aimed at the high-frequency read paths rather than sprinkled everywhere.
• Custom validators encoding medical safety rules, rejecting invalid combinations at the boundary.
• Domain modelling across records, prescriptions and allergies, backed by API tests.

What I took from it

In a safety-critical domain, validation is architecture: stated once, testable in isolation, impossible to forget at a new call site.

The problem

Dynamic German tariffs reprice every hour, so running an appliance at the wrong time quietly costs money. The data is public, but nobody wants to read a price curve to decide when to do laundry.

What I built

• Live pricing from the Energy Charts API through a Next.js server route acting as a proxy.
• A sliding-window search for the cheapest block long enough to finish before your deadline.
• A savings calculator that answers in euros, not percentages.
• Flat rate, appliance duration and deadline persisted in localStorage.

What I took from it

The algorithm was the easy half. The value appeared when the output stopped being a price curve and became “start it at 14:00, you'll save €0.62”.