Migrate B2B SaaS from Zapier/Make to Code — Keep the Enterprise Deal
Move the SLA-bearing, SOC 2 in-scope, and customer-facing-audit workflows off Zapier and Make and into TypeScript you can ship under contract — without breaking the live customer flows.
The problem
Most B2B SaaS companies do not start on no-code by accident. The first Zap or Make scenario went in because the founder needed a customer signup to fan out into Slack, Stripe, Notion, and a welcome email, and shipping it in a vendor UI took an afternoon instead of a sprint. Two years and a hundred customers later, that same scenario is doing user provisioning, billing reconciliation, customer-onboarding state transitions, and a "real-time" Salesforce sync that the sales team has put on the pricing page. And then a real enterprise prospect lands in the pipeline. They send the security questionnaire. They ask for the SOC 2 report. They ask, after reading it, where user provisioning happens. The honest answer is "a Zap." The deal does not die on that answer — but the close date slips by a quarter while the team figures out what to do about it.
Enterprise questions no-code cannot answer
The questions enterprise buyers ask are the questions no-code platforms cannot answer cleanly. SOC 2 CC6.1 wants evidence that identity provisioning and access controls are governed; the auditor wants to see who can edit the Zap, who reviewed the last change, and how the Zapier account itself is access-controlled. The customer wants a per-tenant SLA on workflow latency, and Zapier publishes a 99.9% uptime commitment only on Enterprise — a vendor-side credit-back, not a latency SLA you can pass through. The customer wants a tenant-scoped audit log they can query and export, and Make's enterprise-tier audit log captures operator-level events on connections, API keys, and webhooks with 12-month retention — useful for your own ops, useless as a customer-facing audit read. The customer wants real-time webhooks, and the Zapier polling trigger checks the source system on an interval of 1 to 15 minutes depending on plan, so "real-time" is at best a one-minute lag and at worst a fifteen-minute one.
Silent failure queue under multi-tenant load
Underneath all of this is the operational reality that Make's automatic retry handles only rate limits, connection errors, and module timeouts; every other failure class — malformed payloads, downstream contract changes, business-logic exceptions — sits in the incomplete-execution queue until a human walks in and resolves it. For a multi-tenant B2B product, that translates directly into "Customer X's onboarding silently stalled at 11pm on a Sunday and we found out on Tuesday from a support ticket." None of these are theoretical objections from a security questionnaire — they are the operational tax the no-code stack quietly charges as the customer base professionalizes.
What changes for your business
The migration play for B2B SaaS is not "rip out Zapier." It is "identify the workflows that fail enterprise diligence, move those onto code you control, and leave everything else where it works." The cost of a full rewrite is wrong; the cost of letting in-scope automation sit inside a system the auditor cannot evidence is worse. The work is scoped against the workflow inventory — usually a third to half of the Zap and Make footprint — and the rest is left alone because the operational cost-benefit does not justify touching it.
Four things code gives you that no-code cannot
For the in-scope workflows, the rewrite gives the reader's business four things the no-code platform cannot. First, the orchestration runs inside the SOC 2 audit boundary you already have — your repo, your CI, your change-management process, your access controls. The auditor evidences the same controls they already evidence for the application; the workflow stops being a separate vendor system that has to be re-explained every observation period. Second, the runtime is yours, which means the latency SLA is yours to commit to under contract. A Postgres-backed job table, a managed queue like Inngest or QStash, or a small VPS worker — the choice is made against actual concurrency and latency needs, not a vendor's pricing page. Third, the audit log is tenant-scoped from day one. Every workflow run writes a structured event keyed to the customer tenant, queryable through your product, exportable through an API the customer's procurement team will accept. Fourth, the "real-time" integrations stop being polled. Webhook handlers fire on the source system's push and complete in the hundreds of milliseconds, replacing the one-to-fifteen-minute Zapier polling lag with a number the sales team can put on the pricing page honestly.
Strangler-fig cutover per tenant
The path to that without breaking live customer workflows is strangler-fig. The custom handler ships behind a feature flag, runs in shadow mode against a small set of tenants for a week, and the output gets diffed against the existing Zapier or Make scenario before the cutover. Cutover happens per tenant, not big-bang. The old scenario stays paused but not deleted for a rollback window. The new handler logs every run to a tenant-scoped event table, and the alerting, dead-letter queue, and observability go live with the cutover so that the first customer-impacting failure is caught by your system, not by a customer's support ticket. Five to twelve in-scope workflows on a per-tenant rollout typically runs two to four weeks of focused work, and the engagement is sized against the actual inventory before the quote — not against a generic price list.
What gets shipped for a B2B SaaS migration
The deliverable is working code in your repository plus the operational tooling your team needs to own the workflows after the engagement ends. Concretely:
A workflows/ module — one file per migrated scenario, each exporting a typed function that takes the trigger payload and a tenant context and returns a structured outcome. The original Make blueprint or Zapier export is checked in next to it as a reference until the team is confident in the cutover.
A tenant-scoped event table — every workflow run writes one row with the tenant ID, the workflow name, the input payload, the outcome, the duration, and an event ID. This is the table the customer-facing audit-log feature queries and exports against, and the table your operations team queries when a customer asks "did the webhook fire on order 12345?"
An idempotency layer — a processed_events table keyed on the external event ID, every handler wrapped in a transaction that inserts the event row, runs the work, and commits as one unit. The pattern that prevents a retry from double-charging, double-provisioning, or double-creating a record in a downstream system.
A job queue with explicit retry and dead-letter semantics — Postgres-backed with FOR UPDATE SKIP LOCKED for small footprints, a managed queue like Inngest or QStash for higher throughput. Retry-with-jitter, dead-letter on exhaustion, and tenant-scoped alerts on failure go live with the migration, not "next quarter."
A direct webhook ingest path replacing polling triggers — the source system pushes, your handler validates the signature, writes the event, and processes inline or enqueues. The "real-time" claim on the pricing page becomes accurate.
SOC 2 evidence hooks — the workflows live inside the same change-management, access-review, and audit-log discipline the rest of your application already has. The auditor evidences the controls once and maps them across the orchestration layer; there is no separate Zapier-account access review to run quarterly.
A runbook documenting the per-workflow failure modes, the retry behavior, the cost model, and the rollback plan. Plus a handoff session where your team deploys a small change end-to-end and runs the reconciliation script against a simulated downstream outage.
What enterprise buyers ask first
Four questions consistently surface in late-stage B2B diligence: "Show us the workflow controls in your SOC 2 report," "Can you sign a per-customer latency SLA on this integration," "Can our customers query and export their own audit log of every action taken on their tenant," and "How fast does the webhook actually fire end-to-end." The honest answers when the orchestration lives in Zapier or Make are "no, it is in a separate vendor," "no, our vendor will not commit to one," "no, our vendor's audit log is operator-level not tenant-scoped," and "between one and fifteen minutes depending on the plan." The honest answers after the in-scope workflows are migrated are "yes, here is the section," "yes, this is the queue and this is the alerting we monitor it against," "yes, here is the export API," and "hundreds of milliseconds." The deal gets unblocked because the technical answers stop being apologies.
Proof this pattern lands
BoostFrame Engineering AI (BFEAI) runs the orchestration layer for seven production applications on a TypeScript and Postgres stack we built ourselves — webhook ingestion, idempotent handlers, tenant-scoped event logs, and a Postgres-backed job table with retry and dead-letter semantics. The internal automation it powers — 200K+ AI-assisted keywords generated, 1,500+ AI scans run, 7,000+ sites automated for paying customers — runs on the same patterns we migrate B2B SaaS workflows onto. BFEAI is not a multi-tenant B2B SaaS in the same shape as the reader's product, and we do not pretend it is. What transfers is the architecture: the idempotency discipline, the tenant-scoped event model, the strangler-fig cutover, the queue semantics, and the SOC 2-friendly change-management story. The B2B-specific work — the per-tenant SLA shape, the customer-facing audit-log API, the access-provisioning workflow your auditor will sample — is what the engagement architects against your specific deal pipeline and compliance regime. The author is Bill Fackelman, co-founder and CTO of BoostFrame Enterprise AI.
Outcomes you should expect
What this delivers
- Close the enterprise deal that surfaced the SOC 2 workflow-controls question — by moving the in-scope orchestration into a system your audit can actually evidence.
- Sign a per-customer SLA on workflow latency because the runtime is yours, not a polling cadence inside a SaaS your vendor will not commit to.
- Ship customer-facing audit logs that join workflow events to tenant IDs — instead of an enterprise-tier export from a no-code platform that does not know which of your customers triggered which run.
- Cut the customer-data-staleness window on inbound webhooks from a 5-to-15-minute Zapier polling lag to the latency of your own handler.
Industry data
By the numbers
Zapier states it does not sign a Business Associate Agreement on any plan and that customers should not use it to store, send, or automate anything involving PHI — which forecloses an entire class of B2B SaaS deals the moment a healthcare-adjacent buyer asks where regulated data lives in your stack.
Zapier's polling triggers check for new data on a default 15-minute interval on the Free plan, with custom polling intervals of 1 to 15 minutes only on Pro, Team, or Enterprise — meaning a customer-facing webhook reliability claim of 'real-time' is at best a five-to-fifteen-minute lag depending on the plan you are paying for.
Make.com restricts audit logs to enterprise customers only, with a 12-month retention window and logged events that cover connections, webhooks, API keys, teams, and data stores — but not the per-record customer-tenant reads that a SOC 2 auditor expects to see for a multi-tenant B2B product.
AICPA's SOC 2 CC6.1 logical access criterion requires evidence of identity provisioning, role-based access, and access review controls over information assets — auditors look for documented provisioning and deprovisioning workflows, and a Zap or scenario doing that work is itself in audit scope as the system performing the control.
Make.com's automatic retry covers only RateLimitError, ConnectionError, and ModuleTimeoutError; other error types 'usually require changes in the incomplete execution and manual resolving' — meaning a multi-tenant B2B workflow that fails mid-execution for a single customer will not self-heal under SLA.
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
Our biggest enterprise prospect asked for our SOC 2 report and then asked where user provisioning happens. The answer is 'a Zap.' How bad is that?
It is the kind of finding that delays a deal rather than kills it — but only if you can describe a remediation plan with a date on it. SOC 2 CC6.1 puts identity provisioning and access control in scope as a system. If the system performing that control is a Zapier workflow, the auditor will want evidence of who can edit it, who reviewed the last change, what the change log shows, and how access to the Zap account itself is governed. Most teams in this position commit to a migration timeline for the in-scope workflows, leave the marketing and internal workflows on Zapier, and ship the rewrite before the Type II observation window closes.
We sell on per-customer SLAs. How do we sign one when our middleware is Zapier and they will not sign an SLA to us?
You cannot, in the strict sense. Zapier publishes a 99.9% uptime commitment only on Enterprise, and even that is a vendor-side credit-back arrangement, not a latency SLA you can pass through to your own customers. The migration play is moving the SLA-bearing workflows onto your own infrastructure where you control the queue, the retry semantics, and the observability, so that the customer-facing SLA is something you can actually measure and report against. Workflows that do not touch the SLA — internal notifications, sales-ops handoffs — stay where they are.
Enterprise buyers want customer-facing audit logs that show every action taken on their tenant. Can no-code give us that?
Not in the shape buyers want. Make.com's enterprise-tier audit log captures organization-level events — connections changed, webhooks edited, API keys rotated — with 12-month retention. That is an operator audit log, not a customer audit log. A B2B SaaS customer asking for 'every action on my tenant' wants per-record reads and writes joined to a tenant ID, queryable through your own product, exportable on their schedule. The path to that is owning the persistence layer your workflows write into and emitting structured events to a tenant-scoped log table — neither of which a Zap or scenario exposes.
Our 'real-time' integration with Salesforce is a Zapier polling trigger. Customers are complaining about stale data. What is actually happening?
Zapier polling triggers check the source system on an interval, not on a push from the source. The default on the Free plan is 15 minutes; Pro, Team, and Enterprise can drop that to 1 minute. The minimum is one minute, and the worst case is the full interval — so a record created in Salesforce at 10:00:01 may not appear in your system until 10:14:59 on a 15-minute interval, or 10:00:59 on a 1-minute interval. If you have been marketing real-time, you are between fifty-nine seconds and roughly fifteen minutes off depending on the plan. A direct webhook from Salesforce into a custom handler runs in the hundreds of milliseconds.
How do we migrate without breaking the customer workflows that are running today?
Strangler-fig. The custom handler ships behind a feature flag, runs in shadow mode against a subset of tenants for a week, and the output gets diffed against the Zapier or Make output before the flip. Cutover is per-tenant, not big-bang. The old scenario stays paused but not deleted for a rollback window, the new handler logs every run to a tenant-scoped event table, and the dunning, alerting, and observability go live with the cutover so the first customer-impacting failure is caught by your system, not theirs. Most B2B SaaS engagements migrate five to twelve in-scope workflows on a per-tenant rollout over two to four weeks.
Make.com only retries three error classes automatically. What does that mean in practice for a multi-tenant workflow?
It means a single customer's failed run sits in the incomplete-execution queue until someone goes in and resolves it. A rate-limit, a connection drop, or a module timeout self-heals; a malformed payload from a customer integration, a downstream API contract change, or a business-logic exception does not. In a B2B context the operational cost of that is a support engineer fielding a 'why didn't this fire?' ticket and clicking through a scenario UI for each failure. The custom-code replacement puts retries, dead-letter handling, and tenant-scoped alerts on a job queue your team controls.
How much of our Zapier and Make footprint actually needs to move?
Usually a third to half of it. The in-scope set is whatever touches SLA-bearing customer workflows, regulated data, customer-tenant boundaries, customer-facing audit logs, or the access provisioning your SOC 2 audit cares about. Everything else — internal Slack notifications, sales-ops handoffs, marketing automations — stays on the no-code platform because the cost-benefit does not justify a rewrite. We scope against your workflow inventory before quoting so the engagement is sized to what actually has to move.
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.