the first thing you notice when data comes in from a crisis is that it isn't data. it's noise that used to be people.
in the hours after the beirut port explosion in 2020, i was one of a group of volunteers building a platform to help families find missing people. i was the one making the technical calls, which mostly meant deciding how a system should behave when everything feeding it is broken. what came in wasn't structured records. it was a whatsapp message forwarded through forty phones, a hospital list photographed sideways, a facebook post where the same name appeared three different ways in three comments, kareem, karim, karem, depending on who was transliterating from arabic and how steady their hands were. crisis data arrives the way human desperation arrives: broken, contradictory, partial, and urgent.
the problem the team had to solve, stated simply, was to take everything anyone was saying about anyone and turn it into something a family could actually use. that's clean to write and was not clean to do.
the hard part wasn't scale, it was consistency, or the total lack of it. one record had a first name and a neighbourhood. another had a full name and a photo but no location. exact matching, the obvious approach, would have failed immediately, because a search for ahmad misses the record filed under ahmed, and georges misses jorge. so i built the matching to reason about similarity rather than equality, scoring how likely two records referred to the same person across several weak signals at once and surfacing ranked possibilities instead of a yes or no. it was the right call, and i made it in a few hours, with the problem in front of me and no time to weigh it the way you're supposed to.
the rest was making sure the thing stayed standing. i built the backend to assume failure, connections dropping, clients going offline mid-submission, traffic with no ceiling i could predict, because a crisis platform that goes down when it's needed most is worse than none at all. i made writes idempotent so a retry couldn't corrupt anything, cached hard, tuned the queries and the indexes, and leaned on serverless and a cdn so it could absorb spikes instead of buckling. it held with no downtime through the weeks that followed. i also built the chatbot that routed people to the right resources, so a human didn't have to answer the same question a thousand times.
people describe this kind of work as "built in 72 hours," and the phrase has always sat wrong with me. it makes it sound like an endurance feat, a story about not sleeping. what seventy-two hours actually is, is a sustained state of judgment under uncertainty, where the cost of getting something wrong isn't a missed deadline, it's a family that doesn't find out what happened to their son. you make the call with what you know and you don't get to revisit it.
i got things wrong too. the early interface i designed asked too much of people in acute distress, optimising for clean records when, in the first hours, more incomplete records would have been worth more than fewer complete ones. i fixed it, slower than i should have.
i want to be careful about the number that gets attached to this. the platform was accessed more than thirty-three million times in the weeks after the explosion. that is not thirty-three million lives changed or families reunited. many were the same people checking the same record, many were journalists, many were people with no missing relative who needed to know someone was trying to impose order on the chaos. what it honestly represents is reach under genuine desperation, a thing people turned to when there was nowhere else, at a scale that reflects the size of the crisis and not the size of anyone's ambition. it held. that's the honest version.
what it left me with is a question i now ask on everything i build: what is the worst thing that happens if this breaks. for most software the answer is bounded. a checkout fails and the user retries. for that platform it wasn't bounded, and building with that knowledge changes how you work in ways that show up as architecture and test coverage rather than as visible caution. i didn't choose to learn it this way. but it shapes how i build more than anything else i've done.