Solutions / Watchmaking and luxury
Systems for the workshop, the boutique and the service centre, built by an engineer with three years in a luxury group's research and innovation unit.
These scenarios are illustrations. None of them describes a client.
Quality
What we would build
An inspection station that photographs each dial under fixed lighting and highlights areas that differ from approved parts. Inspectors confirm or overrule each flag, and those decisions become the reference for the next model update.
PyTorch, Anomalib, ONNX Runtime
Boutiques
What we would build
A briefing assistant that reads the client's purchase history, service records and advisor notes, then writes a one-page brief in the advisor's language with a source for every line. It runs on infrastructure the house controls and stores nothing of its own.
Mistral, vLLM, Salesforce API
Brand protection
What we would build
An agent that watches selected marketplaces, matches listings to references from their photos and descriptions, and checks any visible serial or warranty card against authorised-dealer allocations. It builds a case file for each suspicious listing, and the team decides what to pursue.
Playwright, DINOv2, Python, PostgreSQL
After-sales
What we would build
An intake assistant that reads the photos and the client's description, finds similar past repairs and drafts a preliminary quote with the likely operations and parts. A watchmaker validates or corrects the draft, and each corrected quote joins the examples used for the next ones.
PyTorch, FAISS, FastAPI, Salesforce API
Supply planning
What we would build
A demand model that combines waiting lists, boutique sell-through, enquiries and local events to estimate unconstrained demand per market. Planners see the estimate next to their current split and decide the allocation themselves.
LightGBM, Darts, dbt, Snowflake
Watchmaking works in small series, with near-perfect parts and clients who expect to be recognised. The data is thin compared with mass retail and often confidential, so the methods differ: anomaly detection that learns from good parts, models that run in the workshop, and assistants that keep client details inside the house.
A good line produces very few rejects, so inspection models learn what a correct part looks like and flag anything that departs from it.
Unreleased references and supplier data stay on site. Training and inference run on hardware in your own facility.
Clienteling data describes clients who expect complete discretion, so assistants read it in place and keep no copy outside your systems.
Systems point at what deserves a second look, and the grading stays with watchmakers and inspectors.
Yes, with the right lighting. Most of the effort goes into the capture station: lighting angles, camera and fixtures. We prototype the station with your parts before training anything.
Usually. Anomaly detection trains on good parts and needs defective ones only to check what it catches. A handful per defect type is enough to start, and the set grows as inspectors confirm new flags.
Nowhere new. The assistant reads from your CRM with the advisor's existing permissions and runs on servers you control, in Switzerland or in the region where the data already lives.
Yes. A smaller house can start with one focused tool, such as after-sales quotes or inspection of a single component, and add others later. Our pages for SMEs and large enterprises, linked below, show how each kind of project runs.
We start with a feasibility study on your own data, so you see results before anything is promised.