Ask the ones that catch quiet, dangerous gaps: Are any keys exposed? Is the database locked down? Can a logged-out visitor reach private data? Can one user see another's? Are passwords handled safely? Is there a privacy policy and a backup? If you cannot confidently answer these, that uncertainty is your launch blocker.
Information current as at 5 July 2026
Most security problems in AI-built apps are not exotic; they are the same handful of gaps, and they are all findable before launch with the right questions. This article gathers them into one honest checklist. The aim is not to frighten you out of launching, but to make sure you launch knowing where you stand, rather than discovering it when a customer or a scanner does.
The first and highest-value question: can anyone find a key or password by looking at your app. Open your page source and network requests and search for anything that grants access, keys, tokens, database credentials. None should be visible to the browser. Confirm your secrets live in server-side settings, not in frontend code, and that nothing sensitive was committed to a public code repository. An exposed key is the most common serious hole in AI-built apps and among the easiest to exploit, because a scanner finds it without any skill. If you find one, rotate it and move it server-side before you go anywhere near launch. This question alone catches the failure that most often goes wrong first.
The next cluster is about your data, and it has several parts because data fails in several ways. Is your database locked down with access rules, so it is not readable by anyone who finds its address. Can a logged-out visitor reach data or pages that should require a login, tested by actually trying while signed out. Can one logged-in user see another user's records by changing an identifier in the address. Are customer passwords never stored readably, but handled by a proper authentication service. Each of these is a specific, testable question, not a vague worry, and each maps to a leak that is common in AI-built apps. If any answer is yes-they-can-reach-it or I-am-not-sure, you have found a gap that matters more than any feature.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
Then look at access and control. Do the accounts that run your business, your host, database, domain, email and payments, have two-factor authentication switched on, so a stolen password is not enough. Are permissions scoped to least privilege, so no single key or account can do everything, keeping the blast radius of any compromise small. Is there separation between admin power and ordinary use, rather than one all-powerful account. These questions are about limiting damage rather than preventing every incident, and they are the difference between a slip you rotate away and a slip that hands someone the whole business. They are quick to check and quietly decisive.
Finally, the obligations and the safety net. If you collect any personal information, is there an honest privacy policy describing what you hold and why, and are you meeting the baseline expectations of the Australian Privacy Principles, which is general information rather than legal advice. Do you have a working, tested backup, so a bad deploy or a breach is recoverable rather than fatal. And do you have even a rough plan for the day something goes wrong: how you would contain, assess and, if serious, notify. Launching is not just about the app working; it is about being ready for it to be used, and misused. Work through these questions honestly. Where several answers are uncertain, especially around exposed keys, open data, or password handling, that uncertainty is itself the finding, and it is a sound reason to get a second opinion before real customers arrive rather than after.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.