The 10 questions to ask your app before you ask for a review

Your app is in production, it has users, and nobody senior has looked at it as a whole. Before you pay someone to review it, there are questions you can ask yourself, today, without opening any code.

This is not a security test. It is a way to understand where you stand and what to tell whoever ends up looking at the app. They are in order: access, data, code and continuity.

Access

1. Who has administrator access to the code, the database and the hosting, and does everyone use two-factor authentication? Include people who have left. Does the freelancer who built the first version still have the key? An administrator account without 2FA is the cheapest door to open.

2. Where are the passwords and API keys, and has any of them ended up in the repository, in an email or in a chat? A key that was once in the git history is still there even after it is deleted from the file. If it was, treat it as compromised and replace it.

Data

3. If you create two test accounts, can one see the other's data? It is the simplest test and the most revealing. In apps with several companies or several customers, this is where the worst problem usually sits.

4. Is there a key or file in the browser, in the mobile app or in a public bucket that bypasses the data access rules? In services like Supabase, the public key goes to the browser on purpose, and the only thing between it and your data is the access rules. A service key in the wrong place brings that down.

5. Do you know where personal data lives and who can see it? If you can't say it in two sentences, you don't yet have a map of your data, and GDPR expects you to have one.

Code

6. Do the routes that touch money, permissions or other people's data check who is asking? Being logged in is not enough. The question is: can this user do this to this record? That is how a user ends up promoting themselves to administrator by changing a field in the request.

7. What happens when someone sends data you didn't expect? Text where a number should be, a huge file, an extra field. Does the app validate on the server or only in the form?

8. When were the dependencies last updated, and does anyone look at the warnings? Running npm audit (or the equivalent for your stack) takes a minute. The warnings are not always urgent, but it helps to know which ones there are.

Continuity

9. If everything disappears today, how long until you are back, and how many hours of data do you lose? Have you ever restored a backup, or do you only know it exists? A backup that has never been restored is a hope, not a backup.

10. If tomorrow you find out there was an incident, who does what, and who do you have to tell? With personal data, GDPR generally requires you to notify the supervisory authority (the CNPD, in Portugal) within 72 hours of becoming aware, unless the breach is unlikely to put people at risk. Having this thought through beforehand saves you hours on the worst day.

How to read the answers

A rule of thumb, mine and with no science behind it: if you answer "I don't know" to more than three, it is worth getting outside eyes. If you answer "yes" to everything without having checked, get them too, because that is what tends to be wrong.

What this list is not

It does not replace a review of the code and the database, a penetration test, or legal advice on GDPR. It is there so you know where you stand and so you arrive at that conversation with better questions. If your app was built with tools like Lovable, Bolt or Cursor, also see what we usually find in reviews of AI-built apps.

---

Want to go through these ten questions with someone? Take the 2-minute diagnostic or book a 30-minute conversation.