The Night I Almost Lost My SaaS to a Bug

It was 2:17 AM when everything broke. I know the exact time because I had been watching that timestamp in my browser tab for forty-something minutes, hitting deploy, watching my app fail in some new way, hitting deploy again.

I should have been asleep. I had class in the morning.

But earlier that evening, three users had signed up. Not test accounts I made myself — real people. Strangers who found my platform somewhere on the internet, read the landing page, clicked Register, and trusted me with their phone numbers. Three people. And somewhere between that moment and me stepping away to eat, my webhook had started returning HTTP 500 errors on every request.

This wasn't a hobby project. This was supposed to be money. I had spent weeks building this — a WhatsApp automation platform that let businesses manage multiple brands and phone numbers from one dashboard. Real clients were interested. I had shown it to people, explained the vision, watched them nod. Now it was broken, quietly, at 2 AM, and real users were sitting inside it.

I opened my Firebase console. Firestore looked fine. Documents were writing correctly, collections were there. I checked my Vercel deployment — green. Build succeeded. The kind of green that makes you feel like you are going crazy.

I went to the raw logs.

Seven lines deep, buried in a wall of timestamps:

TypeError: Cannot read properties of undefined (reading 'brandId')

A missing brand fallback. That was it. The webhook was receiving an inbound WhatsApp message, trying to look up which brand it belonged to, finding nothing — and then crashing completely instead of handling the gap gracefully. Six weeks of work. Three real users. All of it hanging on one missing null check.

Here is the thing nobody prepares you for: debugging alone at 2 AM in Nigeria is a specific kind of lonely. There is nobody to call. Your friends are asleep. Stack Overflow might give you an answer by morning. Your brain is running on fumes and something that used to feel like excitement.

You open a new tab. You paste the error into Google. You find a thread from 2020 that is almost your problem but not quite — different framework, different version, a slightly different symptom. You sit there trying to translate a stranger's half-answer into your codebase, your architecture, your specific version of every package. The clock keeps moving. The logs keep saying 500.

What nobody tells you is that at 2 AM, the bug stops feeling like a technical problem. It starts feeling like a verdict. Like maybe you are not as good as you thought. Like maybe the people who said "why are you building this" were right. Every failed deploy feels a little more personal than the last one.

I fixed it at 3:41 AM.

One line. if (!brand) return res.status(200).json({ received: true }). Eighty-four minutes of logs and tabs and cold rice for one line of code. I pushed the fix, watched the build run, saw the 200 responses come through in the logs — and I just sat there. Too tired to celebrate. Too relieved to move.

I kept thinking: what if a user had tried to send a message during those 84 minutes? What if the 500s had triggered a rate limit from Meta? What if I had gone to sleep like a reasonable person and woken up to six hours of silent failures?

The uncomfortable part about building software alone is that you are always one bad push from everything going sideways. No QA team. No code review. No one pinging you on Slack to say "hey, the webhooks are down." Just you, your laptop fan, and the logs.

I had not built enough of a safety net. I knew it even before that night — I just kept deferring it because there was always a feature to ship first, always something more exciting than error handling.

The next two days I wrote defensive code. Proper error handling, not just for that webhook but for every edge case I had been pretending would not happen. Real logging that actually told me what failed. Alerts. The kind of boring, unglamorous work that keeps a product alive when you are not watching it.

The platform did not go down that night. The Firestore writes still worked. Most users never knew anything was wrong. But I knew — and that knowing is the thing that changes you.

There is a version of this story where the person closes the laptop and quits. Sees the gap between the vision and the reality of 2 AM debugging sessions and decides it is not worth crossing. I understand that choice. I have seen smart people make it.

What kept me going was not some big picture belief in the product. It was simpler. Those three users. Not a thousand — three. Three people who found something I built, with no marketing budget, no team, no connections, and decided to sign up. That is a real thing. That matters.

One bug does not erase that.

I fell asleep around 4 AM with my laptop still open on the desk. Class the next morning was rough. I was running on five hours and a kind of quiet satisfaction that does not translate well to 9 AM lectures.

But the webhooks were responding. The users were still there. The platform was still standing.

Some nights that is enough.