Security and spend

Two ways an AI-built MVP kills a young company: it leaks customer data, or it quietly runs up a bill you can't pay. Both are avoidable with maybe two hours of attention, and both are almost entirely ignored by the tutorials.

You don't need to become a security engineer. You need to know the four specific mistakes that actually happen.

The four mistakes

1. Leaked secrets

Your API keys and database passwords live in .env.local. If that file reaches GitHub — and it will, if it isn't in .gitignore before your first commit — bots find it within minutes. Public repositories are scanned continuously and automatically.

What happens next depends on the key. A database key means your customer data is readable. A cloud provider key means someone mines cryptocurrency on your account and you get a four-figure bill.

2. Wide-open database rules

Covered in Choosing a cheap stack and worth repeating because it's the most common serious flaw in AI-built apps: a Supabase table without Row Level Security is readable by anyone who finds your API URL, which is in your page source.

Your app looks fine — it only shows each user their own data, because that's what you asked for. But the database will happily hand over everything to anyone who asks it directly, bypassing your app entirely.

Rule: RLS enabled and explicit policies on every table, created at the same time as the table. Verify it in the dashboard yourself.

3. Trusting the browser

Anything that runs in the browser can be changed by the user. All of it. A "delete" button hidden from non-admins is still an HTTP request anyone can send by hand.

So every check that matters has to happen on the server or in the database. When you build anything with permissions, say so explicitly: "Enforce this on the server, not just by hiding the UI. Assume the user can send any request they like."

4. Not validating input

Users type unexpected things. Some by accident, some on purpose. Without validation on the server you get corrupt data, broken pages, and occasionally something worse.

Ask for it explicitly: "Validate this on the server as well as the client. Handle empty values, absurdly long text, wrong types, and special characters."

Data protection, briefly and honestly

Personal information brings obligations from your first user — Australia's Privacy Act if you're here, GDPR the moment you have European or UK users, and something comparable most other places. Personal data, properly covers all of that in full. The founder-level short version:

• Collect less. Every field you don't collect is one you can't leak. Do you truly need date of birth? A phone number?
• Have a privacy policy. What you collect, why, who else sees it, how to get it deleted. Generators are fine to start.
• Be able to delete someone. If a user asks, you must be able to remove their data. Make sure "delete account" actually deletes, rather than hiding.
• Cookie banners are only needed for non-essential cookies — mostly analytics. Using a cookieless analytics tool sidesteps the whole thing.
• Check where your users are, not just where you are. Privacy law follows the user, so an Australian business with European customers is in scope for both.
• Don't store card details. Ever. Use Stripe Checkout and the card data never touches your app.

Keeping your AI bill small

Two things drive cost: how much context you carry, and how much you regenerate.

Keeping your infrastructure bill small

The nasty ones are usage-based services with no cap. Three rules:

• Set spending limits everywhere they're offered. Supabase, Vercel, OpenAI-style APIs — do it on the day you sign up, not later.
• Set billing alerts at a number that would worry you. Finding out at A$60 beats finding out at A$600.
• Be careful with anything per-request. An accidental infinite loop calling a paid API is the classic way to spend hundreds of dollars in an afternoon.

And if you add AI features to your own product: work out the cost per user before you launch, not after. Plenty of products have launched with an AI feature costing more per user than the subscription price.

Do a security review of this project. I'm a non-technical founder about to launch to real users, so explain everything in plain English and tell me how worried to be.

Check specifically:
1. Secrets: anything committed to Git now or in history, anything exposed to the browser that shouldn't be, anything with a NEXT_PUBLIC_ prefix that looks sensitive
2. Database: is row level security on for every table? Show me each policy and explain in plain English who it lets do what. Flag any table where the answer is "anyone".
3. Authorisation: for every action that changes data, is permission checked on the server, or only by hiding UI?
4. Input validation: which endpoints accept user input without validating it server-side?
5. Data exposure: could one user see another's data by changing an ID in a URL or an API call? Show me how you checked.
6. Dependencies: anything with known vulnerabilities?

For each finding give me: what's wrong, what could actually happen, how likely it is, and the fix. Order by real-world risk, not by theoretical severity. Then tell me the three things to fix before I let anyone in.

Search this entire project — including the full Git history, not just the current files — for anything that looks like a credential: API keys, passwords, tokens, connection strings, private keys.

For each one found, tell me:
1. Where it is, and whether it's in the current code or only in history
2. What service it belongs to and what someone could do with it
3. Whether the repository is public or private, and how much that changes the urgency
4. The exact steps to fix it — including that I need to revoke and regenerate at the provider, not just delete the file

Then check my .gitignore and tell me whether anything sensitive could be committed by accident in future. Finally, show me how to set up an automatic check that stops me committing a secret again.

I'm a non-technical founder trying to keep costs predictable. My stack is [list services].

Build me a cost model:
1. Monthly cost at 0 users, 100 users, 1,000 users and 10,000 users, in Australian dollars — with the assumptions you used spelled out, including the USD exchange rate and whether GST applies
2. Which service becomes expensive first, and what specifically triggers it
3. Which of these could produce a surprise bill, and what the worst realistic case is
4. Exactly where to set spending limits and alerts on each one, step by step
5. Any free tier limit I'd hit sooner than I'd expect

If my app includes AI features, work out the cost per user per month separately and compare it to what I'd need to charge. Tell me honestly whether the unit economics work.

I'm an Australian solo founder launching a web app that stores [describe what personal data you hold]. My users are mostly in Australia, with some in [the EU / UK / elsewhere]. I have no legal budget yet.

Give me the practical minimum:
1. What I'm legally required to have in place from my first user
2. What I can reasonably defer until I have revenue
3. A plain-English list of what needs to be in my privacy policy for MY specific data, covering each jurisdiction my users are actually in
4. What "be able to delete a user" actually means technically — including data in backups, logs, and third-party services
5. Which of my third-party services process personal data, and what that means for me
6. The three mistakes small startups most commonly make here

Be practical rather than alarmist, and be clear about where you're giving general information rather than legal advice.