MadeForMed

Merging two medical products into one, starting with the interface.

Role: Design system architect
Period: 2026 – Present
Sector: Medical software, France

01The design system is live in production70+ components, design and code in sync, themeable, shipped in production
02We migrated without pausing feature workBootstrap and Tailwind made to coexist, so feature work continues during the migration
03Design and code now stay in sync automaticallyFigma → automated build script → theme rebuilt

MadeForMed builds software for doctors. Two products, sold to the same people, built by two different companies.

MadeForMed is the doctor's working environment: a calendar, video consultations, general patient records, messaging. Odaiji, acquired more recently, is the clinical product: consultations, patient follow-up, prescriptions, lab orders. The real medical software.

Two products, two stacks, two visual languages, one customer. The company decided to merge them into a single product built on Odaiji's foundation, wearing MadeForMed's identity. I was hired to build the design system that makes that merge possible on the interface side.

But the merged product has to carry MadeForMed's identity while keeping the UX doctors already know from Odaiji — and none of it can come at the cost of stopping feature development, because the company still has to ship while the merge happens.

That last point drove every decision after it.

Team: 5 — product manager, me (lead dev and orchestrator), one reviewing developer, one executing designer, one reviewing designer
Stack: TypeScript · React · Base UI · Tailwind v4 · tailwind-variants · Vitest
Tooling: Figma · Zeroheight · GitHub Actions

Three problems to solve before the two products could become one.

Problem 01
Two products with two visual languages had to become one, without redrawing the product from scratch and without losing the UX doctors already know.
Solution
A design system as the harmonisation layer. One themeable foundation, so the merged product can carry MadeForMed's identity while Odaiji's interaction patterns stay intact.
Problem 02
Odaiji ran on Bootstrap. Moving to Tailwind v4 is not a swap: both need a build step, both ship resets and presets, and they cannot coexist.
Solution
Compile the entire Bootstrap layer into a single static CSS file, install Tailwind, remove the Bootstrap dependency, and inject that compiled file into Tailwind. The app looks identical, and migration happens file by file while feature work continues.
Problem 03
Odaiji's front end had duplicated views, components too low-level to reuse, and no theming at all.
Solution
A system built on Base UI primitives, with variants composed through tailwind-variants and a theme layer built entirely on native CSS variables. Piloted on Odaiji Manager, then rolled out to the clinical product.

How we built it, step by step.

Understanding what a merge actually costs

Before any component, the question was what merging two live products really involves. Two databases where the same doctor and the same patient exist twice. Two authentication systems. Two feature sets that have to end up in one codebase.

The team's answer on the data side was a bridge backend acting as an adapter between the two databases, with a shared authentication layer on top. My work sits above that: making sure the merged product reads as one product rather than two apps wearing the same logo.

DatabaseMadeForMed

DatabaseOdaiji

AdapterBridge backend

LayerShared auth

My scopeOne interface

The design system is live in production.

70+ components, themeable end to end, with design and code kept in sync. Running in production on Odaiji Manager and on Odaiji, the clinical product.

We migrated without pausing feature work.

Making Bootstrap and Tailwind coexist turned a weeks-long freeze into an incremental migration the team can run alongside feature work.

Design and code now stay in sync automatically.

Token changes travel from Figma to production through an automated pull request, with a human review as the only gate.

Next case study

Smiirl — 2017 to 2019The customer app of a connected device, built from zero to one.