El problema es la repetición, no la estética
Casi nadie pide un design system porque sus pantallas sean feas. Lo pide porque el tercer desarrollador ha hecho un cuarto desplegable, cada uno con su propio foco, y ya nadie sabe cuál es el correcto. El coste no es la fealdad: son las horas de volver a decidir lo que ya estaba decidido.
Primero los tokens, después los componentes
Una librería de componentes sobre colores escritos a mano es una reescritura esperando su turno. Empezamos por la capa de tokens: color, escala tipográfica, espaciado, radios, y el tema oscuro definido como conjunto y no como parche. Los componentes leen de ahí, así que cambiar la marca es cambiar valores y no salir de caza por los ficheros.
Primitivas accesibles, no reinventadas
Menús, diálogos, comboboxes y selectores de fecha son justo donde los componentes hechos a mano fallan en silencio: navegación por teclado, foco atrapado, lectores de pantalla. Construimos sobre primitivas que ya resuelven eso y gastamos el esfuerzo de diseño en lo que hace tuyo tu producto.
Documentación que no puede mentir
La documentación escrita se desvía el día que alguien edita un componente y se olvida de la página. La que montamos renderiza el componente real desde el código real: lo que lees es lo que se entrega. Cuando dejan de coincidir, lo dice el build.
Qué te queda al final
El sistema es tuyo, en tus repositorios, instalable por tus proyectos. Sin depender de nosotros para añadir una variante. El traspaso incluye la sesión en la que tu equipo hace el primer cambio con nosotros delante: un sistema que nadie del equipo ha tocado es un sistema que se para la semana que nos vamos.