In October 2024, a natural disaster devastated our warehouse operations in Alfafar, Valencia. We lost inventory, equipment, and months of momentum. This is the story of how we rebuilt the operation, improved the systems behind the business, and came back stronger.
Context: A Company Scaling Fast
I founded REUSALIA in April 2023, at age 25. The idea was simple: buy Amazon liquidation pallets, process and test every item, and resell them across marketplaces like Wallapop and eBay. What wasn't simple was building the tech to make it work at scale.
By early 2024, things were going well. We had 2 employees, a growing catalog of thousands of SKUs, custom automation for every part of the business — from reverse-engineered Wallapop extractors to AI-powered product descriptions — and we were outgrowing our space. In April 2024, we made the leap: we moved into an industrial warehouse in Alfafar, on the outskirts of Valencia, to scale operations properly.
It felt like the right move. We had more space, better logistics, room to grow. For six months, we kept building. More inventory. More automation. More structure.
Then, on October 29th, the water came.
The DANA: October 29, 2024
The DANA — Depresión Aislada en Niveles Altos — was a catastrophic weather event that hit the Valencia region with unprecedented force. Alfafar was one of the hardest-hit areas. Streets became rivers. Cars were swept away. The destruction was unlike anything anyone had seen.
Our warehouse flooded. Inventory we'd spent months processing, testing, and categorizing — destroyed. Equipment, shelving, tools — ruined. The internal systems were safe (they lived in the cloud), but everything physical was gone. Months of operational momentum, wiped out in hours.
The first feeling wasn't panic. It was silence. You walk into a space where you built something with your hands, and it's unrecognizable. That takes a moment to process.
The Recovery: Volunteers, Cleanup, and Decisions
What happened next was the most intense management experience of my life — and it had nothing to do with code.
In the days following the flood, help started arriving. Volunteers from across Spain. And military personnel were assigned to our area for a short period. They showed up at our warehouse ready to work, but the recovery still needed priorities: what could be saved, what had to be cleaned first, and what equipment was needed next.
For a few weeks, the work was not engineering. It was operational triage, coordination, and keeping a cold head while the business was physically unusable:
- Triage: What can be saved? What's a total loss? Which areas do we clean first to make other areas accessible?
- People management: Coordinating volunteers, friends, employees, and temporary help without turning the situation into chaos.
- Resource allocation: Limited tools, limited cleaning supplies, limited time before the window of free help closes. You have to maximize every hour.
- Emotional management: Some of these volunteers were themselves flood victims. Military personnel followed orders but needed clear ones. My own employees were processing the shock of potentially losing their jobs.
You don't learn this in a classroom or a sprint retrospective. You learn it standing in ankle-deep mud, making decisions with incomplete information, while trying to preserve enough momentum to rebuild.
The Aftermath: Insurance, Budgets, and Mental Reset
Once the physical cleanup was done, a different kind of work started — and in some ways, it was harder.
Insurance: Filing claims for a small business after a natural disaster is a bureaucratic nightmare. Documenting losses. Photographing everything. Negotiating with adjusters who have seen hundreds of claims that week. Understanding what's covered, what isn't, and how long payments will take.
Budgets: For weeks, we had zero revenue and ongoing costs. Rent, salaries (I kept paying my team), supplier commitments. I had to create financial projections in a scenario with enormous uncertainty: When can we restart? How much will repairs cost? How much inventory can we recover?
Mental reset: This might be the most underrated part. When you've spent a year and a half building something and you see it underwater, you have to make a choice. You can give up — nobody would blame you. Or you can decide that if you're going to rebuild, you're going to do it right. Better than before.
I chose the second option.
Rebuilding: Better Systems, Bigger Team
Two months after the flood, we were operational again. Same warehouse — we repaired it rather than relocate, because the landlord cooperated and the location worked for our logistics. But everything else was different.
Team Growth: From 2 to 5
Pre-DANA, we had 2 employees. After the rebuild, we scaled to 5. The crisis made me realize we were stretched too thin. I needed people I could trust to handle operations while I focused on building the tech infrastructure properly. The new hires were in logistics and warehouse operations — the areas where manual work was bottlenecking our growth.
The Decision to Migrate
Before the flood, our entire business ran on Google Sheets. Inventory, orders, pricing, everything. It worked when we were small, but the cracks were showing: API rate limits, concurrency issues, no audit trail, no real analytics. I'd been thinking about migrating for months but kept pushing it off — "the business can't stop for an engineering project."
The flood changed that equation. We had to stop anyway. When we restarted, I decided we would restart on a real database. That led to the full migration from Google Sheets to PostgreSQL, building a custom ERP frontend on Retool, and restructuring every automation to use proper data models. I wrote about the technical details in another post.
Documentation and Processes
Before the DANA, a lot of knowledge was in my head. How things worked, why certain scripts existed, what the edge cases were. The rebuild forced me to document everything. Not because I wanted to — because I had to. With new team members who needed to learn the systems, and with the painful memory of how fragile everything felt when it was all manual, I committed to writing things down.
Today, every process has documentation. Every script has a purpose documented in a central registry. Every employee knows where to find what they need. This wasn't born from a best-practices book — it was born from watching chaos and deciding to never be that vulnerable again.
What the DANA Taught Me
I'm an engineer. I think in systems, data flows, and optimization. But the DANA taught me things that no technical challenge ever could:
- Leadership is real-time decision-making under uncertainty. When operations are broken and information is imperfect, you learn that a fast good-enough decision beats a slow perfect one every time.
- Resilience isn't about avoiding failure — it's about what you build after. The company that exists today is objectively better than the one that existed before October 2024. Better systems, better processes, better team, better documentation. The flood was the worst thing that happened to us, but what we built afterward is the best version of REUSALIA.
- People management is the hardest engineering problem. Coordinating people with different skills, motivations, and emotional states — while managing your own — is orders of magnitude harder than any distributed systems problem I've ever solved.
- Crisis reveals what's fragile. Every system that broke during the recovery — whether it was a business process that only I understood, or a spreadsheet that couldn't handle concurrent access, or a team that was too small to absorb a shock — was a system that needed to be redesigned. The flood was the ultimate stress test.
- You can't build something meaningful without risk. Moving to the warehouse was the right decision. The flood was bad luck, not bad judgment. I'd make the same move again. What I wouldn't do is build on fragile foundations again.
Where We Are Now
Today, REUSALIA operates with 5 employees. We operate from the same warehouse in Alfafar — repaired, reorganized, and running better than ever. Our tech stack is production-grade: a PostgreSQL database, a FastAPI backend, a custom Retool ERP, automated extractors running every 15 minutes, AI-powered product enrichment, and multi-marketplace listing sync.
We process thousands of SKUs, manage nearly 100 orders per day across 12+ Wallapop accounts plus eBay, and have full visibility into every metric that matters — from chat response times to inventory turnover rates.
None of this would exist in its current form without the DANA. Not because the flood was a good thing — it wasn't — but because it forced the kind of introspection and radical rebuild that you rarely have the courage to do when things are "working fine."
Sometimes the most important engineering skill isn't writing code. It's knowing that when everything breaks, you can pick up the pieces, organize the chaos, and build something better.