El compromiso navideño
La historia de la primera línea de código y por qué nadie dijo "esperemos hasta enero".
25 de diciembre de 2025. 23:47. Mientras el resto de la familia debatía si Die Hard califica como una película navideña (lo es, y esto no está en discusión), alguien abrió una terminal y escribió:
npx crear-siguiente-aplicación@última revisión
La primera confirmación ocurrió a las 11:52 p.m. Contenía un esqueleto de Next.js, un diseño predeterminado y una sección principal que decía "El sistema operativo para ITAD". La sección de héroes sería reescrita a la mañana siguiente. Y nuevamente al día siguiente. Y aproximadamente cuarenta y siete veces más durante los meses siguientes. Si hay algo que es constante en el desarrollo de software es que la primera versión de la sección de héroes nunca es la final.
Por qué el día de Navidad
No por urgencia. No por una fecha límite. Porque la idea llevaba meses dando vueltas, y en algún momento o empiezas o no, y no importa tanto el día concreto que empiezas como el hecho de que empezaste. El 25 de diciembre es un día tan bueno como cualquier otro. Mejor, en realidad, porque nadie envía correos electrónicos el día de Navidad, y la ausencia de correos electrónicos crea un raro foco de atención en el que puede nacer todo un andamio de proyecto.
La idea detrás de ReVend OS no era complicada: las operaciones de ITAD se ejecutan en herramientas que no fueron diseñadas para ITAD. ERP que no entienden de palets. Bases de datos de FileMaker que una persona puede modificar. Hojas de cálculo de Excel que sirven como columna vertebral de un mercado secundario de miles de millones de euros. Grupos de WhatsApp que funcionan como parqués. Todo operador de ITAD lo sabe. Todos en el bar de conferencias están de acuerdo. Nadie había construido la alternativa.
La brecha entre "todos están de acuerdo en que esto debería existir" y "alguien realmente lo construye" se mide en años y excusas. El compromiso navideño fue el fin de las excusas.
Lo que vino después
Enero fue feo. El prototipo tenía una barra lateral, un tablero y modo oscuro. Se parecía a cualquier otra plantilla SaaS en Internet. Funcionó correctamente. Estaba absolutamente desprovisto de personalidad. Pero demostró el concepto: se podía crear una interfaz única que rastreara los activos, administrara los almacenes, manejara la clasificación y se conectara al flujo de ventas. No como cuatro herramientas separadas. Como uno.
Febrero fue la limpieza profunda. Limpieza de código, actualizaciones de dependencias, eliminación de decisiones tomadas a las 2 a. m. que parecían brillantes a las 2 a. m. pero que, en realidad, no lo eran. El tipo de deuda técnica que se acumula en las primeras semanas de un proyecto cuando la velocidad importa más que la estructura. Febrero fue cuando la estructura se puso al día.
Marzo fue cuando todo se volvió real. La base de datos despertó. Los datos simulados dieron paso a tablas reales, consultas reales y relaciones de clave externa reales. Los activos obtuvieron números de serie que persistieron. Las calificaciones obtuvieron estructura. Los almacenes obtuvieron zonas. La plataforma dejó de ser una demo y pasó a ser software.
La filosofía del versionado
Eda versión tiene un subtítulo. No porque los subtítulos sean necesarios, sino porque nombrar cosas te obliga a articular qué cambió y por qué es importante. "The Warehouse" (v0.2.0) trataba sobre las vistas del primer piso. "Assembly Line" (v0.3.0) trataba de probar flujos de trabajo. "The Database Awakens" (v0.16.0) trataba sobre la migración de datos simulados a Postgres. "La Gran Migración" (v0.20.0) trataba de terminar lo que comenzó la v0.16.0.
El registro de cambios se lee como una novela. No porque lo valoremos, sino porque un registro de cambios debería contarle la historia de un producto. Lo que construimos. Por qué lo construimos. Lo que aprendimos mientras lo construíamos. Si no puede explicar su registro de cambios a un cliente, no puede explicar su producto.
Lo que aprendimos
Empezar es fácil. Continuar es difícil. El compromiso navideño duró cinco minutos. Los siguientes tres meses requirieron todo lo demás. El compromiso no está en la primera línea de código. Es en el compromiso número 500, cuando el trabajo ya no es nuevo o emocionante sino simplemente necesario, y lo haces de todos modos porque el problema que estás resolviendo no ha desaparecido.
La industria ITAD todavía funciona con hojas de cálculo. Los grupos de WhatsApp todavía tienen 187 miembros. Las listas de acciones todavía están desactualizadas el jueves. Los auditores todavía llegan y encuentran documentación en cuatro sistemas diferentes. El impuesto FileMaker todavía se está pagando. Nada sobre el problema ha cambiado. Lo que significa que todavía se necesita todo lo relacionado con la solución.
25 de diciembre de 2025. Una terminal. Un comando. Un mensaje de confirmación que decía "compromiso inicial" porque cada proyecto comienza con un "compromiso inicial" y a nadie se le ha ocurrido un nombre mejor para el comienzo de algo.
La sección principal decía "El sistema operativo para ITAD". Fue reescrito a la mañana siguiente. Algunas cosas en el software nunca cambian. Empezar es uno de ellos.