La extracción de la biblioteca que cambió todo

El momento en que un producto se convierte en una plataforma

Hay un momento específico en la vida de cada producto en el que deja de ser una aplicación única y comienza a ser una plataforma. Para nosotros, ese momento fue el 26 de noviembre de 2025 — cinco días después del primer commit.

Fue entonces cuando extrajimos nuestra interfaz de chat, sistema de archivos virtual y utilidades centrales en tres paquetes separados y reutilizables: @fulldiveVR/chat-ui, @fulldiveVR/vfs-ui y @fulldiveVR/core-ui-utils.

Suena como una decisión de ingeniería. En realidad, fue una decisión de negocio.

Por qué lo hicimos en el día cinco, no en el día cincuenta

La sabiduría convencional dice: no extraigas bibliotecas demasiado pronto. Espera hasta que tengas un segundo caso de uso. Espera hasta que la API se estabilice. Espera hasta que “sepas lo que estás construyendo”.

Ignoramos todo eso.

Aquí está el porqué: sabíamos que tendríamos múltiples productos utilizando la misma interfaz de chat. Sabíamos que la UI de gestión de archivos sería necesaria en diferentes contextos. Y sabíamos que cuanto más esperáramos, más estrechamente estarían acoplados estos componentes a las necesidades específicas del dashboard.

En el día cinco, el paquete chat-ui tenía alrededor de 2,000 líneas de código. Limpio. Bien definido. Fácil de extraer.

Si hubiéramos esperado hasta el día cincuenta, habría tenido 10,000 líneas con docenas de dependencias implícitas en el estado, enrutamiento y configuración específicos del dashboard. Extraerlo entonces habría sido un proyecto de varias semanas en lugar de uno de dos días.

Lo que extrajimos

chat-ui — Todo el sistema de renderizado de chat. Burbujas de mensajes, respuestas en streaming, archivos adjuntos, cambio de agentes, visualización de llamadas a herramientas. Todo lo que un usuario ve cuando habla con un agente de IA.

vfs-ui — La interfaz del sistema de archivos virtual. Árboles de archivos, creación de carpetas, vistas previas de archivos, arrastrar y soltar, diálogos de carga. Todo lo que un usuario ve al gestionar sus archivos.

core-ui-utils — Utilidades compartidas. Tokens de tema, hooks comunes, primitivas de diseño. Lo que tanto chat-ui como vfs-ui necesitan pero que ninguna debería poseer.

Cada uno se convirtió en un paquete npm versionado, publicado en GitHub Packages, consumido por el dashboard como cualquier otra dependencia.

Los retornos compuestos

Para febrero de 2026, nuestro paquete chat-ui estaba en la versión 2.0.12. Eso son docenas de lanzamientos — cada uno mejorando la experiencia de chat en cada producto que lo utiliza.

Cuando añadimos mensajes de tareas en segundo plano a chat-ui, cada producto recibió mensajes de tareas en segundo plano. Cuando añadimos mensajes de usuario colapsables, cada producto recibió mensajes de usuario colapsables. Cuando arreglamos un bug de renderizado, cada producto recibió la solución.

Este es el retorno compuesto de la extracción temprana: las mejoras se multiplican.

Pero va más allá de la reutilización de código. Extraer estas bibliotecas nos obligó a pensar en nuestras interfaces. ¿Qué necesita saber un componente de chat? ¿Qué necesita un gestor de archivos de su aplicación anfitriona? Estas preguntas, planteadas temprano, produjeron respuestas más limpias de lo que habrían sido meses después, cuando todo estaba enredado.

El beneficio inesperado: velocidad

Aquí está lo que más nos sorprendió. Después del costo inicial de extracción (alrededor de dos días de refactorización), nuestra velocidad de desarrollo aumentó.

¿Por qué? Porque los límites eran claros. Trabajar en la experiencia de chat significaba trabajar en chat-ui. Trabajar en la gestión de archivos significaba trabajar en vfs-ui. No había “cambié el chat y rompí el gestor de archivos” porque eran literalmente paquetes separados con interfaces definidas.

Los nuevos miembros del equipo podían trabajar en chat-ui sin entender toda la base de código del dashboard. Los informes de errores podían ser triados inmediatamente al paquete correcto. Las pruebas eran más rápidas porque cada paquete tenía su propia suite de pruebas.

La lección para otros creadores

Si puedes dibujar un cuadro alrededor de un componente — si tiene entradas claras, salidas claras y un propósito claro — extráelo temprano. No esperes el mítico “momento adecuado”. El momento adecuado es cuando la extracción es pequeña y barata. Esa ventana se cierra más rápido de lo que piensas.

Extrajimos tres bibliotecas en la primera semana. Ochenta días después, han sido actualizadas más de cien veces. Cada actualización mejoró cada producto. Ese es el tipo de apalancamiento que convierte a un pequeño equipo en uno productivo.