Before you launch: security, licences and the checks people forget

Claude can write working code very quickly, but working and safe are two separate questions. An app can look finished and behave perfectly in every demo while still letting one customer see another customer’s orders.

Building faster doesn’t mean you can skip the checking. This is what I’d go through before you tell anyone about your app. I’ve written it for beginners, and you can do most of it yourself with Claude’s help.

Run the automatic checks

The commands are the same on Windows and Linux. Run them from inside your project folder, and if one reports something you don’t understand, paste the output into Claude.

npm run lint
npm test
npm run build
npm audit
npx license-checker --summary

npm run lint
npm test
npm run build
npm audit
npx license-checker --summary

On GitHub, open your repo’s Settings and find the security section. Turn on Dependabot alerts and secret scanning, which warn you about unsafe packages and about keys or passwords that were committed by accident. What’s available depends on your plan, so check what you have.

Security: the habits that prevent disasters

You don’t need to be a security expert, but you should know what you’re protecting and where it usually goes wrong. These are the things I’d check first.

Secrets stay on the server. Passwords and API keys never go in your code, and never in anything that runs in the visitor’s browser. If the browser can see it, so can anyone who opens the developer tools.

Don’t trust anything people send you. Every input needs checking on the server, not just in the form. Without that, a visitor can send text that tricks your database into running something it shouldn’t, which is what SQL injection is.

Check permissions on the server for every request. Hiding a button in the interface doesn’t stop anyone calling the endpoint behind it. Each request has to confirm that this person is allowed to do this specific thing, and this is the mistake that lets one customer see another’s data.

Limit how often people can try things. Rate limiting stops someone guessing passwords or running up your bill with thousands of requests. Alongside that, give every key the least access it needs. If a key only needs to read, it shouldn’t be able to write.

Protect the accounts around the app. Use a password manager and two-factor authentication on GitHub, your host, your domain registrar and your email. Someone who gets into one of those can often reset the passwords on all the others.

The usual reference point is the OWASP Top 10, a list of the most common serious web security risks. Claude knows it well, so you can ask it to review your project against it.

Licences: are you allowed to use it?

Most of your project is other people’s open-source code, pulled in as packages, and each one comes with a licence that sets out what you’re allowed to do with it.

The same applies to fonts, icons, photos and music. Being free to download doesn’t make something free to use commercially. It’s also worth deciding on a licence for your own code. For a private product, “all rights reserved” is normal.

The legal basics

If you collect names, email addresses or anything else personal, you need a privacy policy. In the UK and EU that’s a requirement of GDPR, the data protection law. Most tracking and advertising cookies also need the visitor’s consent before they’re set, and if you’re selling something, you need terms that explain what people are buying and how refunds work.

UK organisations that handle personal information often have to pay a data protection fee to the ICO as well. For the smallest organisations it’s £52 a year, or £47 if you pay by direct debit (roughly $65). Its website has a short self-assessment that tells you whether you need to. If you have customers in the US, there’s no single federal equivalent, but state laws such as California’s CCPA can apply, so check where your customers are.

This is general information, not legal advice. If you’re unsure, ask a professional.

Make sure you can recover

Something will go wrong at some point, so the question is how quickly you can recover. Back up the database, and restore a backup at least once so you know it actually works. Keep test and live separate as well, with test keys and a test database while you’re building, so a mistake can’t touch real customers.

Find out how to roll back before you need to. Your host keeps previous deployments, so find out where that option is while nothing is broken. Add error tracking, such as Sentry, and an uptime checker, so you hear about problems before your customers tell you.

Set spending limits on anything billed by usage, especially AI and email services. And keep your packages up to date, because security fixes come out all the time. Dependabot will tell you when something needs attention.

Then try it like a customer

Automated checks won’t catch everything. Open the app on your own phone and go through every screen. Make a real booking or payment, check the confirmation email arrives, and check your spam folder too. Then give it to someone who hasn’t seen it and watch them use it without helping. Problems that every tool missed tend to show up quickly that way.

While you’re at it, ask Claude to “add SEO metadata, a sharing image, a sitemap and a robots file”, so search engines and social media display the site properly.

The checklist

1. Lint, tests, build and npm audit all pass.
2. Secrets are on the host, not in the code. Secret scanning and Dependabot are on.
3. Claude has reviewed it against the OWASP Top 10, and you’ve fixed what it found.
4. Licences for code, fonts and images are checked.
5. Your privacy policy is published, plus cookie notice and terms if you need them.
6. Backups work, and you know how to undo a bad release.
7. Error tracking and spending limits are set.
8. You’ve tested it on a real phone, with a real booking or payment.

Haven’t got this far yet? Start with how to put your artifact on the web.

This kind of checking is a big part of what I do. AI writes code quickly, but someone still has to take responsibility for it. If you’ve built something and want it looked over properly, see my services or get in touch for a free 20-minute call.