En octubre de 2024, una catástrofe natural devastó nuestras operaciones de almacén en Alfafar, Valencia. Perdimos inventario, equipos y meses de impulso. Esta es la historia de cómo reconstruimos la operación, mejoramos los sistemas que sostienen el negocio y volvimos más fuertes.
Contexto: una empresa que crecía deprisa
Fundé REUSALIA en abril de 2023, con 25 años. La idea era sencilla: comprar palets de liquidación de Amazon, procesar y probar cada artículo, y revenderlo en marketplaces como Wallapop y eBay. Lo que no era sencillo era construir la tecnología para que funcionara a escala.
A principios de 2024, las cosas iban bien. Teníamos 2 empleados, un catálogo creciente de miles de SKUs, automatización a medida para cada parte del negocio — desde extractores de Wallapop creados mediante ingeniería inversa hasta descripciones de producto generadas con IA — y nos estábamos quedando pequeños en nuestro espacio. En abril de 2024 dimos el salto: nos mudamos a una nave industrial en Alfafar, a las afueras de Valencia, para escalar las operaciones como es debido.
Parecía la decisión acertada. Teníamos más espacio, mejor logística, margen para crecer. Durante seis meses seguimos construyendo. Más inventario. Más automatización. Más estructura.
Entonces, el 29 de octubre, llegó el agua.
La DANA: 29 de octubre de 2024
La DANA — Depresión Aislada en Niveles Altos — fue un fenómeno meteorológico catastrófico que golpeó la región de Valencia con una fuerza sin precedentes. Alfafar fue una de las zonas más castigadas. Las calles se convirtieron en ríos. Los coches eran arrastrados. La destrucción no se parecía a nada que nadie hubiera visto antes.
Nuestra nave se inundó. El inventario que habíamos pasado meses procesando, probando y categorizando — destruido. Equipos, estanterías, herramientas — arruinados. Los sistemas internos estaban a salvo (vivían en la nube), pero todo lo físico desapareció. Meses de impulso operativo, borrados en cuestión de horas.
La primera sensación no fue pánico. Fue silencio. Entras en un espacio donde construiste algo con tus propias manos y está irreconocible. Eso lleva un momento asimilarlo.
La recuperación: voluntarios, limpieza y decisiones
Lo que vino después fue la experiencia de gestión más intensa de mi vida — y no tuvo nada que ver con escribir código.
En los días posteriores a la inundación, empezó a llegar ayuda. Voluntarios de toda España. Y se asignó personal militar a nuestra zona durante un breve periodo. Se presentaban en nuestra nave dispuestos a trabajar, pero la recuperación seguía necesitando prioridades: qué se podía salvar, qué había que limpiar primero y qué equipos hacían falta a continuación.
Durante unas semanas, el trabajo no fue de ingeniería. Fue triaje operativo, coordinación y mantener la cabeza fría mientras el negocio estaba físicamente inutilizable:
- Triaje: ¿Qué se puede salvar? ¿Qué es pérdida total? ¿Qué zonas limpiamos primero para hacer accesibles las demás?
- Gestión de personas: Coordinar voluntarios, amigos, empleados y ayuda temporal sin que la situación se convirtiera en un caos.
- Asignación de recursos: Herramientas limitadas, material de limpieza limitado, tiempo limitado antes de que se cerrara la ventana de ayuda gratuita. Tienes que aprovechar cada hora al máximo.
- Gestión emocional: Algunos de esos voluntarios eran ellos mismos damnificados por la inundación. El personal militar seguía órdenes, pero necesitaba que fueran claras. Mis propios empleados estaban asimilando el golpe de poder perder su trabajo.
Esto no se aprende en un aula ni en una retrospectiva de sprint. Se aprende de pie, con el barro hasta los tobillos, tomando decisiones con información incompleta, mientras intentas conservar el impulso suficiente para reconstruir.
Las secuelas: seguros, presupuestos y reinicio mental
Una vez terminada la limpieza física, empezó otro tipo de trabajo — y, en cierto modo, fue más duro.
Seguros: Tramitar reclamaciones para una pequeña empresa tras una catástrofe natural es una pesadilla burocrática. Documentar las pérdidas. Fotografiarlo todo. Negociar con peritos que han visto cientos de reclamaciones esa misma semana. Entender qué está cubierto, qué no, y cuánto tardarán en pagar.
Presupuestos: Durante semanas tuvimos cero ingresos y costes que seguían corriendo. Alquiler, salarios (seguí pagando a mi equipo), compromisos con proveedores. Tuve que elaborar proyecciones financieras en un escenario de enorme incertidumbre: ¿Cuándo podremos reanudar? ¿Cuánto costarán las reparaciones? ¿Cuánto inventario podremos recuperar?
Reinicio mental: Esta quizá sea la parte más infravalorada. Cuando has pasado un año y medio construyendo algo y lo ves bajo el agua, tienes que tomar una decisión. Puedes rendirte — nadie te lo reprocharía. O puedes decidir que, si vas a reconstruir, lo vas a hacer bien. Mejor que antes.
Elegí la segunda opción.
La reconstrucción: mejores sistemas, equipo más grande
Dos meses después de la inundación, volvíamos a estar operativos. La misma nave — la reparamos en lugar de mudarnos, porque el casero colaboró y la ubicación encajaba con nuestra logística. Pero todo lo demás era distinto.
Crecimiento del equipo: de 2 a 5
Antes de la DANA teníamos 2 empleados. Tras la reconstrucción, escalamos a 5. La crisis me hizo darme cuenta de que íbamos demasiado al límite. Necesitaba personas de confianza que gestionaran las operaciones mientras yo me centraba en construir bien la infraestructura tecnológica. Las nuevas incorporaciones fueron en logística y operaciones de almacén — las áreas donde el trabajo manual estaba haciendo de cuello de botella en nuestro crecimiento.
La decisión de migrar
Antes de la inundación, todo nuestro negocio funcionaba sobre Google Sheets. Inventario, pedidos, precios, todo. Funcionaba cuando éramos pequeños, pero las grietas empezaban a notarse: límites de la API, problemas de concurrencia, ausencia de registro de auditoría, ausencia de analítica real. Llevaba meses pensando en migrar, pero seguía posponiéndolo — "el negocio no puede pararse por un proyecto de ingeniería".
La inundación cambió esa ecuación. Teníamos que parar de todos modos. Cuando reanudamos, decidí que lo haríamos sobre una base de datos de verdad. Eso dio lugar a la migración completa de Google Sheets a PostgreSQL, a construir un frontend de ERP a medida sobre Retool y a reestructurar cada automatización para usar modelos de datos como es debido. Escribí sobre los detalles técnicos en otro artículo.
Documentación y procesos
Antes de la DANA, mucho conocimiento estaba en mi cabeza. Cómo funcionaban las cosas, por qué existían ciertos scripts, cuáles eran los casos límite. La reconstrucción me obligó a documentarlo todo. No porque quisiera — porque no me quedaba otra. Con nuevos miembros del equipo que necesitaban aprender los sistemas, y con el recuerdo doloroso de lo frágil que parecía todo cuando era manual, me comprometí a dejarlo por escrito.
Hoy, cada proceso tiene documentación. Cada script tiene un propósito documentado en un registro central. Cada empleado sabe dónde encontrar lo que necesita. Esto no nació de un libro de buenas prácticas — nació de ver el caos y decidir no volver a ser tan vulnerable nunca más.
Lo que me enseñó la DANA
Soy ingeniero. Pienso en sistemas, flujos de datos y optimización. Pero la DANA me enseñó cosas que ningún reto técnico podría enseñarme:
- El liderazgo es tomar decisiones en tiempo real bajo incertidumbre. Cuando las operaciones están rotas y la información es imperfecta, aprendes que una decisión rápida y suficientemente buena gana siempre a una lenta y perfecta.
- La resiliencia no consiste en evitar el fracaso, sino en lo que construyes después. La empresa que existe hoy es objetivamente mejor que la que existía antes de octubre de 2024. Mejores sistemas, mejores procesos, mejor equipo, mejor documentación. La inundación fue lo peor que nos pasó, pero lo que construimos después es la mejor versión de REUSALIA.
- La gestión de personas es el problema de ingeniería más difícil. Coordinar a personas con distintas habilidades, motivaciones y estados emocionales — mientras gestionas el tuyo propio — es órdenes de magnitud más difícil que cualquier problema de sistemas distribuidos que haya resuelto.
- La crisis revela lo que es frágil. Cada sistema que se rompió durante la recuperación — ya fuera un proceso de negocio que solo yo entendía, o una hoja de cálculo incapaz de soportar accesos concurrentes, o un equipo demasiado pequeño para absorber un golpe — era un sistema que necesitaba rediseñarse. La inundación fue la prueba de estrés definitiva.
- No puedes construir algo significativo sin riesgo. Mudarnos a la nave fue la decisión correcta. La inundación fue mala suerte, no mal juicio. Volvería a dar el mismo paso. Lo que no volvería a hacer es construir sobre cimientos frágiles.
Dónde estamos ahora
Hoy, REUSALIA opera con 5 empleados. Trabajamos desde la misma nave en Alfafar — reparada, reorganizada y funcionando mejor que nunca. Nuestra pila tecnológica es de nivel producción: una base de datos PostgreSQL, un backend en FastAPI, un ERP a medida en Retool, extractores automatizados que se ejecutan cada 15 minutos, enriquecimiento de productos con IA y sincronización de publicaciones en múltiples marketplaces.
Procesamos miles de SKUs, gestionamos casi 100 pedidos al día repartidos entre más de 12 cuentas de Wallapop más eBay, y tenemos visibilidad total sobre cada métrica que importa — desde los tiempos de respuesta en el chat hasta las tasas de rotación de inventario.
Nada de esto existiría en su forma actual sin la DANA. No porque la inundación fuera algo bueno — no lo fue — sino porque forzó el tipo de introspección y reconstrucción radical que rara vez se tiene el valor de hacer cuando las cosas "funcionan bien".
A veces la habilidad de ingeniería más importante no es escribir código. Es saber que, cuando todo se rompe, puedes recoger los pedazos, ordenar el caos y construir algo mejor.