What to prepare before an app health check

You do not need a technical specification to ask for an app review. A short description of what the app does, what worries you and who controls its accounts is enough for an initial conversation. The detailed access can be agreed after the review scope is clear.

Use this checklist if an AI tool helped build your app, a previous developer has left, or the app is about to serve real customers. It is also useful when you are asking several developers to quote for the same work.

Explain the job the app does

In a few sentences, say who uses the app and what they need to complete. Name the most important journeys: for example, a customer signs up, books a time and pays; a staff member sees the booking and changes its status. Say whether the app is a prototype or live, and whether real people, personal data or payments are involved.

If something is broken, describe the action, the result you expected and what actually happened. A screenshot with test data can help. “The second customer can see the first customer's booking when I change the URL” is more useful than “security is broken.” Do not send a real customer's record to demonstrate it.

List the accounts and owners

You can write a simple inventory without sharing any credentials:

If you cannot answer one of these, say so. Unknown ownership is itself something to investigate. For the current app health check, the standard scope is one web app with one code repository, one database project and its hosting. Larger or unusually connected apps are scoped separately.

Record what changed recently

Note a recent release, builder prompt, package update or configuration change if the problem started afterwards. Include when you first saw the issue and whether it affects everyone or a specific account. If there are logs or error messages, keep them available for the review, but remove personal data before sharing examples in an enquiry.

Also say what decision you need: “Can we launch?”, “Can we repair this rather than rebuild?”, or “Which failure should we fix first?” That helps the reviewer give you a useful conclusion instead of an undirected list of code comments.

Agree safe access after the scope is clear

Do not paste passwords, API keys, database exports or customer details into a contact form or AI chat. Once the work is agreed, arrange the least access needed through the relevant platform's sharing controls. Use test accounts and a test copy when possible. Agree before anyone changes the live system.

The output should be understandable to the owner: what was checked, what was found, what matters first and what remains unknown. The illustrative health check report shows the format. If you have the short description and account inventory above, tell me about your app; missing technical details can be worked through together.