Part one made the case for why an AI-built MVP needs engineering attention before you scale acquisition. This is the practical half: the specific areas where early products break, what to inspect in each, and the questions to answer before growth turns a small gap into a large incident.

None of this requires a security team. Most of it requires an afternoon and a willingness to look.

1. Authentication Is Not Authorization

Your login working does not mean your application is secure. These are two different questions:

• Authentication: who is this person?

• Authorization: what is this person allowed to access?

Imagine your SaaS holds thousands of customer records, and each request looks like:

What happens if the user changes that number by hand? Can they reach /api/customer/38125?

If your backend simply trusts the identifier arriving from the browser, you have a serious authorisation problem — and it's the single most common one in fast-built products.

The UI hiding another customer's records does not solve this. The backend must enforce the rule.

2. Think in Boundaries

Every application has boundaries, whether or not anyone has written them down:

• Customer A should never see Customer B.

• Employees need different privileges from each other.

• Admins hold powerful actions.

• Partners get limited access.

• Some information should never reach the browser at all.

• Some operations should only ever happen server-side.

Your security model should make those boundaries explicit — ideally written somewhere a new engineer can read in five minutes.

Unclear boundaries are survivable in a prototype. They get progressively more dangerous with every user, employee and integration you add.

3. The Database Deserves More Attention Than the Landing Page

A common AI-development pattern runs: generate schema → connect database → start building features. That works beautifully during prototyping and quietly ships assumptions into production.

Before meaningful growth, inspect:

• access policies

• row-level security

• foreign keys

• constraints

• validation

• indexes

• backup processes

• migration processes

• audit requirements

If you're on Supabase, understand your Row Level Security policies. On Firebase, understand your security rules. If you're running a backend API, confirm that authorisation exists server-side.

Never treat "the frontend doesn't show the data" as equivalent to "the user cannot access the data." They are not remotely the same statement.

4. Protect Your API

Your frontend isn't the only way to interact with your application. Every endpoint can potentially be called directly, by anyone, at any volume.

Work through your own endpoints and ask:

• Expensive AI endpoint: can somebody call it 100,000 times?

• Image upload: can somebody upload unexpected file types?

• Record update: can somebody change the ID?

• Admin action: is the role checked server-side?

Production APIs typically need authentication, authorisation, input validation, rate limiting, payload limits, logging and safe error responses — error messages that don't hand an attacker your stack trace.

The exact controls depend on the risk. The habit of asking doesn't.

5. Protect Your Secrets

API keys that grant privileged access should never end up inside the client application.

Review:

• environment variables

• repositories

• Git history

• deployment environments

• third-party credentials

• admin keys

• database credentials

And one rule that surprises people: if a secret has been publicly exposed, removing it from the latest commit does not make it safe. The history is still there, and automated scrapers watch public repositories continuously.

Rotate it.

6. Payments Need Their Own Threat Model

Stripe makes accepting payments much easier. It does not make payment logic engineering-free.

Think through:

• duplicate requests

• webhook replay

• failed payments

• refunds

• cancelled subscriptions

• access expiration

• subscription upgrades

• race conditions

Never rely exclusively on what the browser reports happened. Payment providers use server-side webhooks precisely because browsers close, crash, refresh, lose connectivity — and can be manipulated.

A payment bug isn't like other bugs. It shows up as a charge on someone's statement.

7. Your AI Features Create Another Boundary

If you're building an AI application, be specific about what leaves your infrastructure. Are you sending:

• customer documents?

• internal business records?

• personally identifiable information?

• confidential data?

• authentication information?

• credentials?

• whole database records?

You need to know what leaves, which vendor receives it, how prompts are constructed, whether logs contain sensitive content, and which users can trigger expensive operations.

AI adds capability. It also increases the number of systems touching customer data — and each one is another boundary to reason about.

Developers themselves are concerned

This isn't founder paranoia. The 2025 Stack Overflow Developer Survey found that 87% of respondents agreed they were concerned about the accuracy of information provided by AI agents, and 81% agreed they had concerns about the security and privacy of data when using them.

Those concerns aren't a reason to avoid AI. They're a reason to build the right controls around it.

8. Monitoring Is Part of Security

Imagine someone discovers an endpoint that should have been protected and hits it 15,000 times overnight.

Would you know?

That's what observability is for. Your system should give you enough information to identify failed authentication attempts, unexpected traffic spikes, application exceptions, slow requests, third-party failures, suspicious patterns and payment failures.

Production software should be able to tell you when it is unhealthy — without a customer having to tell you first.

9. Backups Are Useless Until You Can Restore Them

Founders often tell us: we have automatic backups.

Good. Now the follow-up: have you ever restored one?

A real backup strategy answers:

• What is backed up?

• How often?

• Where is it stored?

• How long is it retained?

• Who can access it?

• How quickly can we restore?

A backup you've never tested isn't a backup. It's an assumption.

How Much Security Is Enough?

Your pre-revenue MVP does not need the cybersecurity organisation of a global bank. That would be wasteful, and waste has its own cost at this stage.

Security should be proportional to:

• the data you hold

• the damage unauthorised access could create

• your customer type

• your regulatory environment

• your transaction volume

• your product maturity

A prototype full of fake data warrants a very different posture from a healthcare application storing patient information. Engineering is the discipline of choosing the appropriate level — not the maximum one.

The Founder Production-Readiness Check

Before significantly scaling customer acquisition, answer these ten:

If your team can't answer these confidently, growth is amplifying uncertainty rather than revenue.