Custom orthopedic and rehabilitation devices · Switzerland
ORTHO-TEAM Gruppe develops and manufactures custom orthopedic and rehabilitation devices and serves patients through a network of specialist centers. What they asked for was an application: at ortho-team.ch/konfigurator a person picks the color and appearance of a device, judges the configuration in 3D in the browser, and exports it as a PDF. Angular and Three.js in front, Nest.js and PostgreSQL behind, an admin panel for the catalog — three weeks of development.
At a glance
The starting point
An orthosis is a visible object worn on the body, often for a long time, and how it looks matters to the person wearing it. ORTHO-TEAM asked for a tool that puts that choice on screen: pick the color and the appearance of the device, judge the configuration in 3D, and leave with a document that records it. It had to sit inside the existing site as a self-contained mini-application.
What we built
A manager uploads a new 3D model, manages its color variants and updates the catalog, and the new entry appears on the front end automatically, with no developer in the loop. Behind that panel, Nest.js and PostgreSQL hold the catalog itself: products, 3D models, color variants and their parameters.
The visualization runs on Three.js, which is what makes the 3D models behave smoothly inside an ordinary page. The client supplied 3D files of the products together with their color variants, and we built dynamic loading for the models and their parameters, so a product and its options come in when they are needed. Looking at the device in 3D and switching a color both happen in the browser, with no plugin and no download.
A configuration is only useful once it leaves the screen. The export saves the chosen setup as a PDF, and that same document is what the client, the manager and production all work from. Simplifying that communication down the chain is what the export was asked for.
The configurator was built as its own Angular application with its own catalog and its own admin, embedded in the client's site at /konfigurator/. The main site keeps its structure and its content; the tool can be extended on its own terms.
Design and devices
The brief was narrow: choose the appearance, judge it in 3D, take the result away as a PDF. That put the work on legibility rather than styling. The person at the screen is judging something they may wear in public for months, and they have no CAD habits to fall back on, so the model has to read as the device itself at a glance. The interface is built around the product, with the catalog and the color options arranged around it and the export sitting at the end of the flow.
What came of it
Every figure here describes delivery: what shipped, how long it took, and what the client can do now without us. The second one is the one that keeps paying, because it removes a recurring internal cost rather than a one‑off task. Performance evidence for a configurator has to be measured after launch — configuration starts, completed configurations, PDF exports — and that instrumentation is a scope item we price in time before the build starts.
Implementation time for the configuratorFront end, API, database and admin panel in one project.
Needed to publish a new model or colorA manager uploads it in the admin panel and the front end picks it up automatically.
Where a customer sees the device in 3DThree.js renders the model in an ordinary tab, with no plugin and no download.
Shared by client, manager and productionThe configuration leaves the browser as a file everyone in the chain can open.
Assistants are largely irrelevant to this build, and the honest answer is to say so. ChatGPT, Perplexity and AI Overviews answer from text they can read, and a 3D scene that holds its state in JavaScript gives them nothing to quote. The configurator was commissioned as a tool for people already on ortho-team.ch, and the scope stopped there. Making the products findable by an assistant is a separate job, and it changes how the pages around the tool are built.
How we ran it
Every project runs on a written plan. This is how this one ran.
We go through the 3D files the manufacturer already has: geometry, materials, how the color variants are separated, what actually needs to be interactive. ORTHO-TEAM supplied product models together with their color options, so this stage was a review of existing assets.
The catalog becomes structured data in PostgreSQL: products, models, color variants, parameters. Nest.js exposes it. From this point the configurator has no hardcoded product list, which is the precondition for the client running the catalog without us.
A Three.js viewer inside the Angular application: dynamic loading of models and their parameters, camera and lighting setup, live color switching on the loaded geometry.
Upload a model, manage its color variants, update the catalog. New entries surface on the front end automatically, with no developer involved.
PDF generation for the finished configuration, embedding the application into the live site at its own URL, and a walkthrough with the people who will maintain the catalog.
Performance evidence for a configurator has to be measured after launch: configuration starts, completed configurations, PDF exports. That instrumentation is a scope item we price in time before the build starts. It was not part of this one, which is why no usage figures appear on this page.
Straight answers
Yours is probably close to one of these. If not, ask it directly.
Ask about your projectSame team, same method
Tell us what you sell and where you sell it. You get a plan like the one above, with the first step priced out and dated before anything starts.
