Verticals / Vertical guide

What breaks in an AI-built B2B SaaS app before launch?

Matt Turley, Continuum. Updated November 5, 2026.

For founders building a multi-user, multi-company SaaS product with AI tools who are about to onboard their first paying business customers.

The short answer

What breaks in an AI-built B2B SaaS app before launch?

Tenant isolation. A B2B app holds many companies' data in one system, and AI-generated code often checks only that a user is logged in, not that the record belongs to their company. Test it as a user from company A against company B's ids, then check roles, invitations and billing.

What is really going on

Consumer apps mostly need to separate one person from another. A B2B app must separate whole organisations, each with several users in different roles, and the boundary is crossed by every query. Forget it once, on one endpoint, and one customer can read another's data.

AI tools handle the first version well: a user, some records, a dashboard. The multi-tenant parts (organisations, memberships, invitations, role checks, per-seat billing) get bolted on later, usually in the interface, and the server and database quietly keep trusting any logged-in user.

Business buyers also test what they are buying. Their first questions are about exactly this: how is our data separated from other customers', who in our company can see what, and can we get our data out.

Where B2B apps go wrong, most common first

  1. Tenant isolation is enforced in the interface only

    How to tell Sign in as a user of company A, then request a record id that belongs to company B directly through the API or URL. If it returns, isolation is missing. The same applies to files, exports and search.

    The fix Put the organisation id on every tenant table and enforce it in the database (row level security) or in a single server-side data layer that every query goes through. Never trust an id supplied by the browser.

  2. Roles are checked on the screen, not on the action

    How to tell A member cannot see the Delete button, but can still call the delete endpoint. Admin-only pages are hidden by navigation, not protected.

    The fix Check the caller's role for the specific action on the server for every write and every sensitive read, and keep the role list small and written down.

  3. Invitations and joining are open

    How to tell An invite link works for any email, never expires or can be reused. Anyone with a matching email domain joins the organisation automatically without approval.

    The fix Tie each invitation to an email, expire it, make it single use and require approval for domain-based joining. Re-check membership on every request.

  4. Billing and access drift apart

    How to tell Seat counts, plan limits and cancelled subscriptions are tracked in one place while access is granted in another. A customer cancels and keeps access, or pays and does not receive it.

    The fix Drive plan and seat state from the payment provider's webhook events, store the state in your database and check it on the server. Our page on webhooks that do not fire lists the usual faults.

  5. No audit trail and no data export or deletion

    How to tell You cannot answer "who changed this and when?", and a customer asks to export or delete their organisation's data. There is no way to do it other than manual database work.

    The fix Record who did what to sensitive records, and build export and deletion for an organisation before a customer asks. Both come up in business sales.

  6. Enterprise asks arrive before you are ready

    How to tell The first larger customer asks for single sign-on, a security questionnaire and a data processing agreement. Each is a project.

    The fix Decide which you will support, price it and sequence it. Prepare honest security answers early; our first security questionnaire page shows how.

How we diagnose it

  1. Create two organisations and attack across them. Make two test companies with several users each. From one, try to read, change and delete everything belonging to the other through every endpoint and file path.
  2. Test each role against each action. Build a small table of roles and actions and try every cell by calling the server directly, not by clicking buttons.
  3. Read the data layer. We read how queries are built and find the ones that do not carry the organisation filter, since one missing filter is one breach.
  4. Follow a subscription through its life. Subscribe, add seats, upgrade, fail a payment, cancel and check what access is granted at each point.
  5. Try the invitation and joining flows as an attacker. Reuse, forward and guess invite links; join with a lookalike email; remove a user and check their access ends at once.

What fixing it changes

  • Organisation isolation is enforced centrally in the database or data layer, and tested across two tenants.
  • Every action checks the role on the server.
  • Invitations are single-use, expiring and tied to an email.
  • Plan and seat state comes from billing events and is enforced on the server.
  • Audit records, export and deletion exist for an organisation.

When you do not need us

If your product is single-tenant per customer (each customer has their own deployment or database), much of this does not apply. If you have no customers yet and a simple role model, work through the cross-tenant test yourself first. It takes an afternoon and finds the worst problem.

Your next step

A Ship Check includes a security and data read of exactly this: who can reach what. If your backend is Supabase, the Supabase security review focuses on row level security policies, keys and storage with corrected SQL.

Ship Check, $299: A senior engineer reads your codebase and sends a written verdict (fine, fixable or rewrite), what will break first, a security and data read, and a costed plan, within 48 hours of repo access or it is free. It has a 7-day money-back and is credited against a Ship Fix. Or: Get the Supabase security review.

Get a Ship Check, $299 →See all services and prices →
FAQ

Straight answers

Is row level security enough for multi-tenancy?
It is a strong foundation when the policies are written around organisation membership and tested. It is not enough alone: roles, invitations, storage and any use of the service role key still need their own checks.
What is the single most important test?
Log in as a user from one company and request another company's record ids directly. If anything comes back, stop and fix isolation before onboarding a second customer.
Do I need SSO to sell to businesses?
Not at first. Many small and mid-sized buyers accept email and password with multi-factor authentication or social login. Larger buyers often require single sign-on, so plan for it, but build it when a deal needs it.
Keep reading
How do I know if Supabase RLS is off, and what do I do?By symptom. Row level security off means anyone with your public key can read or change that table. How to check in a minute, the six ways RLS fails, and the fix.A customer sent us a security questionnaire. Where do we start?By stage. Your first customer security questionnaire: what they are really asking, how to answer honestly with evidence, and the controls to put in place first.What breaks in an AI-built app after Demo Day?By stage. After demo day or investor attention: a signup spike, technical questions and an app built to be demoed. What breaks first and what to do this week.Why is my Stripe webhook not firing?By symptom. Stripe is usually sending the event and your server is refusing it. How to read the delivery log, the six usual causes, and the fix for each.What breaks in an AI-built health app before launch?By vertical. Health apps built with AI tools: whether HIPAA applies, vendors that need a BAA, patient data in logs and AI prompts, and access control. Not legal advice.What breaks in an AI-built marketplace app?By vertical. Two-sided marketplaces built with AI tools: seller onboarding, payouts, fees, refunds, disputes and who sees whose data. What breaks and how to test it.
Sources
  1. 1. OWASP: Broken Access Control, OWASP: The risk category for missing tenant and role checks on the server.
  2. 2. Supabase: Row Level Security, Supabase: Writing policies around the caller, including membership-based patterns.
What breaks in an AI-built B2B SaaS app before launch?