What we check first

Start with the failure people can actually see.

“The app is broken” can mean many different things. A release may fail before it goes live, one page may stop loading, users may be signed out unexpectedly, or production may behave differently from a developer’s computer. We begin with the real user problem and work backward to the cause.

Six useful questions

1. What should happen, and what happens instead?
2. Which pages or user actions matter most right now?
3. When did the problem begin, and what changed around that time?
4. Does it fail everywhere or only on certain devices, accounts, or environments?
5. Which outside services does the application rely on?
6. What is the smallest safe result that would get the project moving again?

If the problem involves security or private data, we handle that separately and carefully. The public inquiry form is only for a general description—never passwords, private keys, customer records, or production data.