What Is B2B SaaS?

B2B SaaS means your customers are businesses, not individuals. This single fact reshapes the architecture, the pricing model, the sales motion, and the legal contracts that govern the product. Understanding the implications before you start building saves the ~6 months of retrofitting that most teams discover the hard way at month 18.

How B2B SaaS Differs From B2C SaaS

A consumer SaaS product (Spotify, Headspace, Duolingo) sells one account to one human. The user signs up, pays $10 per month, uses the app on their phone. Architecture-wise the data model is straightforward: each user owns their own data, no one else can see it, the only relationships are user → their content.

A B2B SaaS product (Slack, Linear, HubSpot) sells one account to one company that contains many users. The buyer (often a department head or CTO) is rarely the daily user. Pricing scales with company size — per seat, per workspace, per API call. The data model is fundamentally multi-tenant: company A and company B both use the same application database, but their data must be completely invisible to each other.

This distinction sounds abstract, but it touches every architectural decision. Authentication needs SSO. Authorization needs roles. Billing needs the concept of a workspace. The admin UI needs an "organization settings" tab. Every database query needs a tenant filter. The retrofit cost is significant — most teams accept the multi-tenant overhead from day one rather than rebuilding later.

Technical Requirements Unique to B2B

Multi-tenancy. Every row in every table needs a tenant_id foreign key. Every query needs a WHERE clause that filters by the current user's tenant. Postgres Row-Level Security (RLS) makes this enforceable at the database layer, not the application layer — a single missed filter in application code can leak company A's data to company B. RLS policies move that enforcement into a single, auditable place.

Team management. One company has many users. Users join teams, get invited via email, have their seat revoked when they leave the company. The data model needs a memberships table that joins users to tenants with a role column.

Role-based access control (RBAC). Admin can configure billing and invite users. Manager can edit data. Viewer can only read. The roles need enforcement on every mutation endpoint and every UI surface. Don't skip the API check just because you hid the button — anyone with the network tab can call your API directly.

Audit logs. Compliance teams will ask for them. SOC 2 requires them. Build an append-only audit_events table from day one with: event type, actor user, target resource, timestamp, IP address, before/after diff for mutations. Adding this retroactively means you cannot answer historical questions.

SSO / SAML / SCIM. Enterprise IT departments require their identity provider (Okta, Azure AD, Google Workspace) as the source of truth for user provisioning and de-provisioning. SCIM 2.0 is the protocol for automated user lifecycle — when an employee is offboarded in Okta, your SaaS account is auto-revoked. Most B2B SaaS products gate SSO behind an Enterprise plan tier; SCIM behind the same.

Pricing Models For B2B SaaS

Per seat (Slack, Linear, Notion). Customer pays $X per active user per month. Predictable revenue, easy to forecast expansion, but creates friction on invitations — buyers throttle who they let in.

Usage-based (Twilio, Stripe, OpenAI). Customer pays per API call, message sent, transaction processed, or token consumed. Aligns revenue with customer value but unpredictable for both sides — the buyer cannot forecast their monthly bill without instrumentation.

Tiered flat rate (Linear Standard / Plus / Business). Starter, Growth, Enterprise tiers each priced as a flat per-month rate with feature gates and seat caps. Easy to communicate, but customers right at a tier boundary feel forced to overpay.

Hybrid (Vercel, Supabase). Flat-rate base subscription plus usage-based overage above included thresholds. Most modern B2B SaaS lands here because it captures the simplicity of a base subscription with the alignment of usage-based pricing on the upside.

Annual contracts with discount. Enterprise buyers want a single annual invoice they can plan against, not a monthly credit card charge. Offer a 10–20% discount on annual prepayment to incentivize the contract length and improve cash flow.

Sales Motion And Deal Cycle

B2C converts users via free trial → paid plan. B2B converts buyers via demo → security review → procurement process → signed contract. The deal cycle is longer — 30–90 days for SMB deals, 6–12 months for enterprise — but the deal size is 10–100× larger and churn is lower.

Product-led growth (Slack, Linear, Figma) is the modern B2B counter-pattern: instead of a sales-led demo cycle, the product is free or freemium for individual users, individual users invite their teams, the team account converts to a paid plan once usage crosses a threshold. PLG works when the product has natural collaboration utility for one person before the whole team is on it. It fails for products where one user cannot get value alone.

Architecture Decisions To Make Before You Write Code

First, lock in the multi-tenancy strategy. Shared database with row-level filtering (cheapest, scales fastest) versus schema-per-tenant (better isolation, harder to operate) versus database-per-tenant (best isolation, hardest to operate, most expensive). For 95% of B2B SaaS, shared database with Postgres RLS is the right call. Reserve schema-per-tenant for healthcare, defense, and regulated finance.

Second, plan for SSO from day one even if you do not build it. Reserve the user.identity_provider column. Design your auth flow so an external IdP can replace your password login without a database migration.

Third, separate the User entity from the Membership entity. A user can belong to multiple tenants (someone with both a personal account and a work account, or a consultant invited to multiple client workspaces). If user.tenant_id is your foreign key, this becomes impossible to model later. Instead, users own themselves; memberships join users to tenants with a role.

Fourth, audit_log table from week one. Append-only, never updated, never deleted. Every mutation flows through a writer that emits an audit event. The volume is large but storage is cheap — keep raw events for 1–2 years, summarize older data into rollups.

Most B2B SaaS that scales past 100 customers makes these four decisions in the first month. The ones that don't spend months 12–24 rebuilding the foundation while their competitors ship features.