Selected projects

Problem

• Students get stuck on homework when no teacher is around.
• Teachers cannot see which topics each student has really mastered.
• Course material is spread across files in many formats.

What we built

The tutor explains step by step in text or out loud, reads a photo of the exercise and works through maths on a whiteboard the student shares. It answers from the course material the school imports, saves progress per topic and writes reports for teachers. Access is set by role, and checks for safety, privacy and accessibility run on every release.

Result

In development, with the tutoring engine built as its own package so it can serve more than one school or product.

Problem

• Players and coaches have no data on their own matches.
• Filming a match is easy; turning it into statistics by hand takes hours.

What we built

Two synchronised cameras feed a computer vision pipeline that finds rallies, player positions and ball events. From these it builds statistics, heat maps, highlight clips and coaching notes, shown in a mobile app. Each court has its own unit, which we set up and manage remotely.

Result

Running as a pilot, with statistics and clips from real matches.

Problem

• Patients choosing a lens cannot picture the difference between the options.
• Charts and descriptions of the lenses do not help much.

What we built

An iPhone app that takes the live camera and depth and renders how the scene looks through six types of intraocular lens, in a headset view. Depth comes from the phone’s sensor where there is one and is estimated elsewhere. Voice control and recorded night scenes are included.

Result

Made for education: it shows the kind of difference between lenses, not what one patient will see.

Problem

• In these spectra a huge instrument peak sits right beside the weak signal that matters.
• Existing ways of removing the peak can distort that signal.

What we built

A transformer model with physics built into its checks, trained to separate the two across different microscopes and materials, developed with a research group at the University of Barcelona.

Result

A research prototype. The paper is in preparation, so we do not quote results yet.

Problem

• Callers hang up when they wait in silence.
• Free-form AI is too unpredictable for simple routing.

What we built

Fixed menus handle the routing, so basic calls never depend on the model improvising. Speech and model providers sit behind one interface and can be swapped, and the time to each step of a call is measured.

Result

A working prototype with a test bench that times every step of a call, so speech and model providers are compared on real numbers.

Problem

• Observations of the same event come from very different instruments.
• Finding which ones might belong together is slow by hand.

What we built

A Python backend matches observations by position and time and serves them through an API; a React interface shows the candidates in interactive 3D with live updates. It runs in containers.

Result

In development, with the matching backend and the interactive 3D view built as separate parts.

Problem

• Recaps of long series lose track of who is who.
• Doing it by hand takes days per volume.

What we built

Pages are read and split into scenes, a running story bible keeps names, looks and events consistent, and a script, narration and video are produced with checks at each step. It only uses comics that are free of copyright.

Result

In development, with the story bible keeping names, looks and events consistent from one volume to the next.

Problem

• Tournaments are run on paper and group chats.
• Players and spectators never know the latest score or schedule.

What we built

One app with separate roles for organisers, referees and spectators. It handles several formats and scoring rules for two sports, live match events, player and team management, search and several languages.

Result

Built and working on iPhone, Android and the web.

Problem

• Front desks are busy at the moments guests need them most.

What we built

A voice concierge in the browser that understands guest requests and answers out loud, with bookings simulated for the demonstration.

Result

A working demo with simulated bookings. Connecting it to a hotel’s phone and booking system is the next step.

Problem

• The front desk could not keep up with calls at peak times.
• Leads from property portals waited too long for a reply.
• Copying data between systems caused mistakes.

What we built

We connected the agency’s phone line to a voice assistant that speaks several languages, and set up a WhatsApp assistant that replies as soon as a portal lead comes in. Both share the same lead history and booking calendar, and every unusual case is reviewed by a person.

Result

Calls and portal leads are now handled in one workflow, at any hour, with staff reviewing the exceptions.

Problem

• Between 30 and 50% of messages arrive when the clinic is closed.
• Health-related data falls under the strictest GDPR category.
• One wrong answer could lead to a formal complaint.

What we built

The assistant works in three steps. Common questions are matched to answers the clinic has approved and sent word for word. Other questions are answered only from verified documents, with the source shown. Anything else is passed to a member of staff.

Result

The target is fewer than one unsupported answer in 10,000. The system is waiting for the clinic’s final testing and sign-off.

Problem

• Orders, stock, prices and payments were handled by phone and on paper.
• Key knowledge was held by one employee.
• Verifactu e-invoicing deadlines required changes.

What we built

A system in five parts: a central message queue, a shared database, an AI model hosted on the company’s own server, a security layer that logs every action, and ordering by WhatsApp and phone in three languages.

Result

Estimated value of €100,000 to €120,000 per year, based on hours saved, fewer errors, avoided penalties and orders taken outside office hours.

Problem

• Invoices were entered and matched by hand.
• Each valuation took about two hours of research.
• CRM records had to be corrected by hand.

What we built

Four new modules on the existing platform, each separated for security, with checks on every AI request and an AI model hosted on the agency’s own server for sensitive data.

Result

Target: a valuation draft based on comparable properties in about five minutes, and no more manual CRM corrections.

Problem

• Order preparation relied on experience and paper lists.
• Managers spent their time chasing status updates.

What we built

We mapped the processes, moved orders to a digital workflow and gave the team the data it needed to work on its own.

Result

Order preparation time fell by about 50%, and the team now works independently with modern tools.

Problem

• Every order needed a salesperson.
• Customers could not see stock or prices.

What we built

Stock and price data was connected to a self-service ordering channel, and the sales team moved its focus to key accounts.

Result

Customers now order on their own at any hour with live stock and prices, and the sales team spends its time on key relationships.

Problem

• Most decisions went to management.
• Processes were not written down.

What we built

Written processes, clear decision rights and supporting tools so the team could act without waiting for approval.

Result

More decisions are made without escalation, and managers spend their time improving the business instead of running every task.