◇ Could this help me?
Yes. All three are correct and they are the right three, because each one is invisible until it is expensive: without tests you cannot tell a working change from a breaking one, without observability you learn about failures from users rather than from your own systems, and personal data written to logs is the single most common way a small app creates a real legal exposure. The advice to let a payment provider handle card data is especially worth following, since taking card details yourself pulls the entire system into a compliance scope that is expensive to satisfy and easy to fail. General practice.
My app was built quickly and is heading to real users. Audit it against three things and be blunt about what is missing. First, tests: tell me what a minimal test suite would cover for the paths that would hurt most if they broke, and write the first few. Second, observability: identify the critical components, and tell me what to log and what to alert on so I find out about a failure before a user tells me. Third, personal data: trace every place user data is written to logs, error reports, or third-party services, flag anything that counts as personally identifiable information, and confirm no card data is touched directly rather than being handled by a payment provider. Give me the list ordered by risk, not by effort.