Senior Engineering for B2B SaaS Startups — Close Enterprise Deals
Multi-tenant RBAC, SSO and SCIM, audit logs, and per-seat plus usage billing — engineered so enterprise deals close on your roadmap, not your engineering team's.
The problem
The thing nobody warned the founders about is that "B2B SaaS" stops meaning one thing the moment the first enterprise prospect signs an NDA. Up to that point, the product is a single-org tool: one user, one workspace, one credit card, maybe a Postgres column called user_id and a feature flag or two. After that point, every single layer of the stack starts being asked to do something it wasn't designed for.
Security questionnaire as deal-blocker
The security questionnaire arrives first. It wants SAML 2.0, OIDC, SCIM 2.0 for provisioning, an audit log of every administrative action with at least 12 months of retention, role-based access enforced server-side, encryption at rest and in transit, a documented incident-response process, and a SOC 2 Type II report. The prospect has marked roughly 80 of these items as "required to proceed." None of them are individually hard. Together, they are a quarter of engineering work that produces zero new product features, and the sales team would like it done in three weeks.
Hybrid pricing the billing layer can't carry
The pricing conversation arrives second. The prospect doesn't want your published plan. They want a flat platform fee, a per-seat price for their 400 users, a usage-metered component for API calls or processing volume, and a one-off custom feature that nobody else is asking for. The CFO wants one invoice. Stripe's hybrid-pricing data shows roughly 22% of SaaS businesses had already moved to this kind of mixed model by 2024 — the prospect is not asking for something exotic, they're asking for what they've started getting from every other vendor.
Webhooks, scoped tokens, and audit export
The integration request arrives third. The prospect's ops team uses Zapier and Make. They want a webhook for every event in your system. They also want the ability to call your API with a service account that's scoped to their organization, with rate limits they can see and an audit trail their security team can export.
Per-prospect retrofits compound
None of these are new problems in B2B SaaS. They are the standard cost of moving from $15K ACVs to $50K-plus ACVs — and the 2025 SaaS benchmark study put the cross-cohort median ACV at $26,265, which is exactly the band where these requirements start showing up. What founders typically underestimate is how much engineering quarters this consumes if the multi-tenant, identity, billing, and integration layers were designed for a single-org product and have to be retrofitted one prospect at a time.
What changes for your business
Senior engineering at this stage is the difference between "we built SSO for our biggest customer" and "we shipped the enterprise tier as feature flags on the existing product, and the next three customers turn it on themselves." The same primitives, designed once, kept generic.
Multi-tenant from the database up
Organizations and users are first-class entities, not a "company_name" column. Row-level security in Postgres enforces tenant isolation at the database — so a bug in application code can't leak one customer's data into another's response. BFEAI runs exactly this pattern across seven production apps on a single multi-tenant Postgres, and the cost of designing it in is one decision early; the cost of retrofitting it later is a rewrite plus a customer-trust incident.
Identity as one system, with enterprise SSO as a flag
A single authentication layer that handles email/password, OAuth (Google, Microsoft), and enterprise SAML or OIDC — the latter switched on per-organization when a customer requires it. SCIM 2.0 (RFC 7644 — the standard enterprise IT teams expect for user provisioning and deprovisioning, defined as REST operations over the application/scim+json media type) becomes a webhook endpoint your customer's identity provider can call to keep their user directory in sync with yours. Whether you build the SAML and SCIM layer in-house or buy through a provider — WorkOS publicly lists OpenAI, Anthropic, Cursor, Perplexity, Vercel, and Replit as customers — the architecture should let you swap that choice without rewriting the product.
RBAC the customer's admin can configure
A role catalog scoped per-organization, with permissions enforced server-side on every API endpoint and every database query, not bolted onto the UI. The customer's admin can invite users, change roles, and remove access — and every one of those actions writes to an audit log they can filter and export. That's the table-stakes shape of what SOC 2's Common Criteria (CC1 through CC9 — the only mandatory part of SOC 2, covering access management, logging, encryption, and incident response under the AICPA's Trust Services Criteria) and most enterprise security questionnaires actually want to see.
Hybrid billing on Stripe, reconciled
Per-seat as a linear quantity on one subscription item (Stripe's per-seat docs describe this as items[].quantity on a subscription item), metered usage as a second item on the same subscription, and the platform fee as a third. Custom enterprise plans live as one-off prices in the catalog, not as forks in the code. Usage events get reported idempotently from the product, the webhook stream gets reconciled against the local ledger so out-of-order events don't lose money, and the customer gets one invoice they don't dispute. BFEAI runs a Stripe subscription plus a dual-pool credit ledger reconciled against webhooks across all seven apps — the reconciliation report is what finance actually trusts at month-end.
Webhooks and scoped tokens for customer integrations
A signed webhook for every meaningful event in the system, with replay endpoints for when the customer's listener was down. Scoped API tokens (per-organization, with rate limits the customer's admin can see) so the prospect's ops team can wire Zapier, Make, or their internal tooling without copying anyone's credentials. This is what unblocks the integration line item on the security questionnaire.
The shape of the outcome is simple. Sales stops promising features that need an engineering quarter to deliver. Engineering stops treating every new enterprise customer as a custom project. The next security questionnaire is mostly a copy-paste exercise. The codebase stays one codebase.
What ships in a typical engagement
Engagements are bounded and concrete. The most common shapes for a B2B SaaS startup:
- Architecture audit, two to four weeks. Where the multi-tenant model leaks, where RBAC is enforced only in the UI, where the billing layer can't carry per-seat plus usage, where the audit log won't survive a SOC 2 evidence request, what we'd ship first, and what we wouldn't. The memo is yours whether or not you continue.
- Enterprise SSO and SCIM. SAML 2.0, OIDC, and SCIM 2.0 wired into your existing identity layer, with per-organization configuration the customer's admin can complete themselves. Includes an admin portal pattern your engineers won't be paged about when an Okta assertion fails.
- Billing rework for hybrid pricing. Move a single-product Stripe integration to a system that handles a platform fee, per-seat charges, metered usage, prepaid credits, custom enterprise prices, and out-of-order webhooks. Includes a reconciliation report against Stripe so finance can stop spreadsheet-matching.
- RBAC and audit-log layer. A role catalog enforced server-side on every endpoint, an audit log of every administrative action with retention and export, and an admin UI the customer's IT can use without engineering involvement.
- Migration off a no-code prototype. Lift a Bubble, Retool, or Airtable-backed MVP onto a multi-tenant Postgres with row-level security before the first enterprise prospect asks for SSO. Keep the product feature-set, replace the runtime, ship before the renewal cliff.
- We won't own SOC 2 or ISO 27001 certification. Your security lead and your auditor own those. We engineer inside the controls they define — access management, logging, encryption, change-management, incident-response hooks — so the audit evidence lives in code rather than being bolted on. If you don't yet have a security lead, we'll point you to a compliance partner first.
- We won't write the pricing. Pricing is a CEO and finance decision. Once you've decided on flat-plus-seats-plus-usage, custom enterprise plans, or anything else, we'll engineer it. We'll push back when the proposed pricing is technically achievable but operationally a trap (a metric you can't measure cleanly, a custom plan that implies a custom data model).
- We won't take a single-engineer dependency you can't recover from. Code is documented, infrastructure is described in version control, and an internal engineer can take the work over without a knowledge-transfer crisis. The goal is to leave your team stronger than we found it, not to make ourselves load-bearing.
- We won't build the kind of "enterprise feature" that's really a one-off integration to a customer's legacy on-prem system. That belongs with a specialist integrations vendor. We'll tell you up front which side of that line a request sits on.
Every engagement ends with a short engineering memo: what we built, what's left, where the next failure modes are likely to surface.
What we won't take on
A few hard lines, stated up front so the engagement doesn't surprise anyone:
Outcomes you should expect
What this delivers
- Close enterprise deals without burning an engineering quarter on SSO and SCIM each time a security questionnaire shows up
- Bill correctly when the same customer pays a flat platform fee, per-seat charges, and metered usage — on one invoice, reconciled against Stripe webhooks
- Pass security and SOC 2 audit asks for role-based access and immutable audit logs without redesigning the data model per customer
- Ship the 'enterprise tier' as feature flags on the existing product, not as a parallel fork your team has to maintain
- Cut the time from 'enterprise prospect signed an NDA' to 'enterprise prospect is in production' from quarters to weeks
Industry data
By the numbers
SCIM 2.0 — the standard enterprise IT teams expect for automated user provisioning and deprovisioning — is defined in IETF RFC 7644, published September 2015, and specifies the REST operations (GET, POST, PUT, PATCH, DELETE, plus bulk) over the application/scim+json media type for managing Users and Groups across identity domains.
Stripe documents per-seat pricing as a linear model where each unit on a subscription item represents one user, with the seat count set on the items[].quantity field — the same primitive used to combine a flat per-seat charge with a separate metered usage item in one subscription.
Stripe reports 22% of SaaS businesses adopted hybrid pricing — a flat subscription plus per-seat plus metered usage — by 2024, and recommends modeling it as two products on one subscription so the base fee, per-seat charge, and metered overages reconcile on a single invoice.
WorkOS publicly lists OpenAI, Anthropic, Cursor, Perplexity, Vercel, and Replit as customers running their enterprise identity on its platform, and states that both SAML 2.0 and OIDC are required for enterprise readiness, with SCIM handling the directory sync that keeps accounts current and deprovisions leavers.
The AICPA's SOC 2 framework is built on five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — of which only Security (the Common Criteria CC1 through CC9, covering access management, logging, encryption, and incident response) is required for every SOC 2 audit; the other four are scoped in based on what the company sells.
Across 939 B2B SaaS companies in the 2025 benchmark, the median annual contract value sits at $26,265 (up from $22,357 the year prior), with enterprise-tier ACVs ranging from $50K to $250K+ — the segment where SSO, SCIM, and audit-log requirements consistently appear as deal-blocking line items in security questionnaires.
Live in production today
The same engineering, shipped in production at BFEAI.
I'm co-founder & CTO of Be Found Everywhere (BFEAI), a 7-app AI SaaS platform running today. The work I deliver for clients is the work I do every week on my own platform.
7
Production apps
200K+
Keywords generated
1,500+
AI scans run
7,000+
Sites automated
Common questions
What buyers ask before reaching out
How do I know when it's actually time to add SSO and SCIM?
Two signals: enterprise prospects start asking for it in security questionnaires (usually around the $50K ACV mark), and your support team is manually provisioning users for at least one customer. Before that point, SSO is a feature flag that costs you money in subscription fees and gives you nothing in revenue. The right move is to design the user and identity model so SSO and SCIM can be turned on per-customer when you're ready — without a schema migration.
Do I need WorkOS, or can I build SAML and SCIM myself?
You can build it. SAML 2.0, OIDC, and SCIM 2.0 are all open standards with mature libraries in every language. The reason most B2B SaaS startups buy is not the protocol — it's the long tail of identity-provider quirks (Okta, Azure AD, Google Workspace, OneLogin, PingFederate, JumpCloud each behave slightly differently) and the admin portal your enterprise customers' IT teams use to self-serve their own connections. Buying makes sense when the per-connection price is less than what your engineers cost to debug an Okta SAML assertion at 11pm. We design the integration so swapping providers — or replacing a vendor with in-house code — stays a contained refactor, not a rewrite.
We're already on Stripe with a simple per-seat plan. How hard is it to add usage-based billing on top?
Mechanically, it's a second subscription item with a metered price. Operationally, the hard part is reporting usage events idempotently from the product into Stripe, reconciling against the webhook stream so you catch out-of-order events, and presenting the bill in a way customers don't dispute. We've built this across BFEAI — a Stripe subscription plus a dual-pool credit ledger reconciled against webhooks — and the patterns transfer. Plan two to four weeks for a clean implementation including the reconciliation report finance actually trusts.
Our biggest customer wants a custom plan — different seat tiers, a custom usage rate, a one-off feature. How do we say yes without forking the codebase?
Custom plans are a pricing problem dressed up as an engineering problem. The engineering answer is feature flags scoped to organization, plan attributes stored as data rather than code, and a Stripe price catalog that can carry one-off custom prices alongside the public ones. If the custom 'feature' is really a one-time configuration, it goes in the org settings; if it's a true enterprise-only capability, it gets a flag the sales team can toggle. The codebase stays one codebase. Where this falls apart is when a custom plan implies a custom data model — at that point we push back to sales rather than fork.
What does role-based access actually need to look like for enterprise buyers?
At minimum: an admin role, a regular-user role, and the ability for the customer's admin to invite, remove, and change roles for users in their organization — all visible in an audit log they can export. The next tier up is custom roles defined by the customer (a 'billing-only' role, a 'read-only' role for an auditor), enforced server-side on every API endpoint and database query. The mistake we see most often is RBAC enforced only in the UI, with the backend trusting whatever role the client sends. We design it as a permissions check on every authorization decision, with the role catalog stored per-organization.
We're chasing SOC 2 Type II. Will you take it on?
No. SOC 2 belongs to your security lead and your auditor — we engineer inside the controls they define. What we will do is design the access control, audit logging, encryption, change-management, and incident-response hooks so the Common Criteria controls (CC1 through CC9) are evidenced in the code rather than bolted on at audit time. If you don't yet have a security lead or a defined control matrix, we'll point you to a compliance partner first — trying to engineer for an audit that doesn't yet have a control list is wasted work.
Does it matter that BoostFrame isn't a B2B SaaS company itself?
The architectural primitives are the same. BFEAI runs seven production apps on a single multi-tenant Postgres with row-level security for tenant isolation, custom JWT SSO with refresh-token rotation across all seven, role-based access enforced at the database layer, and a Stripe subscription plus dual-pool credit ledger reconciled against webhooks. Those are the same components a B2B SaaS needs for organizations, roles, cross-product login, and hybrid billing — what changes is the surface area (an admin portal for customer IT instead of an internal admin), not the foundations.
What does a first engagement usually look like?
Typically a two-to-four week architecture audit, or a single bounded build — adding SSO and SCIM for a specific enterprise deal, reworking billing to support per-seat plus usage, designing the RBAC and audit-log layer, or migrating off a no-code prototype that can't carry the enterprise feature set. Every engagement ends with a short engineering memo: what we shipped, what's left, what your next failure mode is likely to be. The handoff is the deliverable as much as the code.
Ready to see if this is a fit?
A 15-minute call. No deck, no slides. We talk about what you're shipping and where engineering is the bottleneck. Either way, you walk away with a senior engineer's read on your situation.