Somewhere over the last couple of weeks you probably built something. You had time off, an idea, and an AI coding assistant that turned a weekend into a working app. That part's the easy part now. The part that still trips people up, every time, is the gap between it works on my laptop and strangers can use this. Here's what I check before anything I build touches a real user, and it takes about an hour.
Five things, in order
1. Security headers
Open your site in a browser, right click, and look at the response headers. If you don't see a Content-Security-Policy, an X-Frame-Options header, and Strict-Transport-Security, your app is missing basic protection against clickjacking, downgrade attacks, and a handful of injection tricks that are older than most of the frameworks we build with now. Most hosting platforms let you set these in a config file or a middleware layer in a few lines. It's the cheapest fix on this whole list, and the one people skip most, because nothing breaks visibly when it's missing. It just means the next bug you ship lands harder than it needed to.
2. Exposed keys
Search your codebase for anything that looks like a key before you push it anywhere public. Keys end up in the same three places by habit: an env file committed by accident, a client-side bundle where anyone can open dev tools and read it in plain text, or an old commit still sitting in git history even after you deleted the line that used it. Rotate anything you find, don't just delete it, because a key that was ever public is a key someone may have already copied. Any server-side key (payment processing, database admin, email sending) should live only on the server. If your frontend needs to call a paid API, put a thin backend in front of it instead of calling it directly.
3. Database access rules
This is the one that actually burned people in 2025. A database layer a lot of AI app builders default to ships wide open unless you turn on row-level access rules yourself, and plenty of generated apps quietly shipped with that switch left off. When a researcher went looking, the flaw turned up live in well over a hundred production apps, exposing hundreds of data endpoints that anyone could query directly with no login at all. If your app has a database, don't assume the default is safe. Confirm a logged-in user can only read and write their own rows, then test it yourself by trying to fetch someone else's data on purpose.
4. Admin routes
If you built an admin panel or an internal dashboard, check that it actually requires a login, not just that it's unlinked from the main site. Nobody knowing the URL isn't access control. It's obscurity, and obscurity lasts only until someone runs a scanner or just guesses the obvious path. I've seen internal tools that could edit any user's account sitting wide open, because the build focused on the customer-facing side and the admin piece got wired up in a hurry at the end.
5. Login checks
Test what happens when a logged-in user tries to act as someone else, not just whether login itself works. One of the bigger incidents in 2025 involved an AI-built app where anyone could get into any other customer's private account just by guessing a public ID already visible in the URL, no password required. It sat there until someone finally tried it. Before you launch, log in as one test user and manually try to view or edit a second test user's data by changing an ID in the URL or in an API call. If that works, it's not an edge case. It means the login system was never actually checking who was asking.
It's an hour of poking at your own app like you're trying to break it, which is a different frame of mind than building it. Make it a habit and it stops being a chore: the last thing you do before any launch, holiday or otherwise, not a one-off favor you ask when you remember to.