Every part of Society Pool passed its own tests. The two login flows worked fine on their own. The notification system worked fine when I checked it by itself. And yet, once everything was running together, two different bugs showed up that neither side could have caught alone.
Why bugs like this hide so well
Most testing happens one piece at a time. You test a login flow. You test a notification. You test a screen. Each one passes, so you move on. The problem is that some bugs only exist in the space between two pieces, not inside either one. Nobody owns that space, so nobody tests it on purpose.
Case one: two logins, one backend, and a load nobody planned for
Society Pool had two separate logins built into a single app. Each login flow was tested and worked fine by itself. What nobody checked was what happened when both were live and used at the same time, at real scale. The backend hadn’t been built with that combined load in mind, and it started struggling under it.
I found out about this fairly late, after the app was already live and both logins were being used together. By then it wasn’t a small fix. We ended up splitting the app into two separate apps, one for each login, so the backend load was cleanly separated too.
Looking back, the real gap wasn’t in either login flow. It was in the assumption that testing them separately was enough. Nobody had asked what happens when both run together at real usage levels, because that question belonged to neither side alone.
Case two: one notification, fired by two apps that didn’t know about each other
The second bug came from a similar gap. After we split the app, we had, in effect, two versions of very similar setups now running side by side. Each one had its own connection to the notification socket. Individually, each one worked exactly as expected: send an event, get a notification. But because both were now connected to the same underlying event, every notification was firing three times instead of once.
This wasn’t a bug you could catch by testing “does the notification work.” It worked. That was almost the problem — it worked too well, from two directions at once. I had to actually understand how the socket connections worked, not just what the notification looked like on screen, to see where the overlap was happening. Once I understood that, I suggested a fix, and it resolved cleanly.
What I check differently now
Both bugs taught me the same thing, just from different angles: the riskiest part of a system isn’t always inside a feature. It’s often in the space between two features that were built assuming they’d be the only one running. Now, when I’m testing something that involves more than one moving part, I ask a different question before I even open a test case: what happens if this runs at the same time as its counterpart, at real scale, without either side knowing about the other? That question alone would have caught both of these bugs earlier.
The takeaway
It’s easy to test each piece of a system and feel confident, because everything passes. But passing tests on two separate pieces doesn’t tell you anything about what happens when they meet. Some of the worst bugs don’t live inside any one part. They live in the handoff between two parts, where nobody was specifically looking.
If you’re testing something built by more than one person, more than one team, or even just more than one version of the same app, it’s worth asking: has anyone actually tested what happens when these run together, not just separately?