Most issues we debug as engineers are in code, configuration, permissions, or infrastructure. That is where we are trained to look. So when something breaks, our instinct is to search logs, recheck setups and run tests.
But sometimes, nothing is broken.
This is a story about a situation where everything was technically correct, and yet the system still “failed” for the user. The problem was not in the software. It was elsewhere.
The System
First, let me give you context about the system. It was a dashboard portal built in React.js that interfaces with the Matrix Cosec biometric system.
- System 1 — Matrix Cosec:
This system handles biometric scans and stores user-related details like User ID, Employee ID and their details. Employees use this internally to mark attendance. - System 2 — React. js Dashboard:
The dashboard syncs data from the biometric system and displays things like leave details, team details and other employee related information, allowing additional access and features to be built upon the base attendance system.
Everything was going good until one day I received a call from the client.
The Problem
The issue reported was that an employee was unable to access the system.
Was the employee in Matrix Cosec? Yes. His attendance and employee info was accessible.
Was the employee registered on our dashboard? No.
So, we created a new access for the employee, verified the data sync and login access, and informed the client.
That should have been the end of it. It was not.
When Things Got Confusing
We assumed a network or access issue. We verified system configuration. We tested across browsers. We checked user permissions and access levels. We double-checked the sync between the two systems.
Everything worked on our side. But when we went back to the client, the access still did not work.
Then, we tested on different Wi-Fi networks. We tried mobile data. Perhaps it was an access restriction. We checked the firewall. There was no restricted rule in place.
At this point, it did not make sense. Everything was fine. What could be wrong?
The Question That Changed Everything
That is when one simple question gave us some clarity. We asked the client, “Can you share the screenshot of the page along the error message of the issue upon login?”
When they shared a screenshot, we were surprised to see that the screen was different from our system. It was a completely different application.
What had happened was: when the employee had been onboarded into the system, they were never told where or how to access our system. They used another internal system URL that looked familiar and assumed it was the correct one. From their perspective, nothing was wrong. They were logging into “the system”.
It was not a technical problem. It was a gap in communication.
The Real Problem
When organisations use multiple systems, people need clarity. They need to know:
- Which system does what
- Where to log in
- How the systems are connected
Without proper onboarding or reference material, users fill the gaps with assumptions. And those assumptions often lead them to the wrong place.
Also, working closely with someone on the client side who understands both the internal process and the system can also help them identify and catch these issues early.
The Bias in our Assumptions
As engineers, we assume certain things.
We assume the user is on the correct system. We assume they have the right URL. We assume they were onboarded properly.
But users don’t think that way. They just think in terms of “the system”.
If something looks like the system and feels like the system, then for them, it is the system.
When those perspectives don’t align, even a perfectly working product can feel broken.
Final Thoughts
This experience reminded me that debugging is not always about fixing logic. Sometimes it is about stepping outside the engineer mindset and seeing the system the way the user sees it, without context and without technical framing.
Engineers see environments, configurations, and logic. Users see one thing: the system. Sometimes, the fastest fix isn’t a code change, but a better question.
And often, the most important debugging tool is empathy.
At Coffee, we are engineering AI and systems that scale with an ease of implementation and onboarding. If you are looking to optimize your system usage and upgrade your workflow processes, reach out to us at coffee@coffeeinc.in.
