There is a moment in every Docusign IAM rollout where someone says "we'll just build that piece ourselves." Sometimes that is the right call. Often it is the start of an 18-month maintenance tax that nobody priced in.

This is a working framework we use with engineering leaders who are staring at the same fork: extend Docusign IAM with a custom Extension App, hire an SI to do it for them, or buy something off the shelf and move on. The vendor docs only push you toward "build on us." The reality is more nuanced.

If you want the broader IAM rollout context first, our Complete Docusign IAM Implementation Guide covers the full picture. This piece zooms in on one decision: who writes the integration.

What "build" actually means inside Docusign IAM

"Build" inside IAM is not one thing. It is a stack of choices, and the cost of each is wildly different.

1. A custom Extension App in the App Center. A standalone web service that Docusign calls into during a Workflow Builder run. You implement OAuth, expose a manifest, and ship verified concepts and actions. Docusign hosts the catalog and the consent flow; you host the runtime.
2. A direct REST integration from your backend. No Extension App, no App Center. Your services call the Docusign eSignature, Agreement Manager, or Workflow Builder APIs directly. Cheaper to start, harder to expose to non-engineers later.
3. A custom step inside Workflow Builder via an extension. Workflow Builder can call extension app steps inside a no-code workflow, which lets your custom logic show up next to native steps for ops users.
4. A homegrown webhook relay. A service that listens to your CRM, ATS, or ERP and triggers Docusign workflows. Looks tiny on day one. Becomes the most expensive thing on your roadmap by year two if you build it without HMAC verification, replay protection, retry queues, and observability.

Each of these is a different commitment. Lumping them together is the first mistake.

What "buy" actually means

"Buy" is also not one thing. There are at least three flavors that show up in IAM projects:

• Native Docusign connectors. IAM ships out-of-the-box integrations for Salesforce, Stripe, Quik!, ServiceNow, and HubSpot. If your use case fits one of these and you do not need exotic field mappings, this is almost always the right answer.
• Third-party Extension Apps in the App Center. Independent vendors publish verified extensions for things like identity verification, payments, address validation, and CRM enrichment. You pay them, Docusign handles the install and consent UX.
• Purpose-built relays and middleware. When the gap is "trigger a Docusign workflow reliably from system X," a focused product like Baton does it without you owning the webhook plumbing.
• An SI build. Technically still custom code, but someone else writes it. The build vs buy question collapses to "who carries the maintenance burden once it ships."

The distinction that matters is not the price tag on day one. It is who owns the integration after it has been in production for 18 months and the Docusign API surface has shifted twice.

The five questions that decide it

We ask these in order. The first "yes" usually settles the call.

1. Is there a native IAM connector or App Center extension that covers 80% of the use case?

If yes, buy. The 20% gap is almost always cheaper to absorb in process than to engineer around. Custom builds that exist purely to bridge that gap have the worst ROI of anything we see.

2. Does the integration touch a system of record that is genuinely proprietary or differentiating to your business?

If the source of truth is a custom internal platform that defines how your company operates, build. The integration is part of your moat, and you do not want a third party in the middle of it. If it is a commodity SaaS your competitors also use, buy.

3. Will non-engineers need to change the workflow once it is live?

This is where Workflow Builder earns its keep. If the answer is yes, the right pattern is almost always: buy or build the connector layer once, then expose configuration to ops users through Workflow Builder steps. A direct backend integration that requires an engineering ticket every time legal wants a new approver is a future complaint waiting to happen.

4. How sensitive is the data crossing the boundary?

Extension Apps make you the OAuth provider. As Docusign's own developer guide makes clear, you are responsible for the OAuth endpoints and for validating every incoming request. That is a real security surface. If the data is high-sensitivity (PII, financial, health), you may want that surface owned in-house. If it is low sensitivity and a vendor already has SOC 2 + the right region story, buy.

5. How tolerant is the workflow of silent failure?

This is the question most teams underestimate. Docusign Connect retries failed webhooks with an increasing backoff starting around 5 minutes, which is fine for most scenarios but means a misconfigured listener can drop events for a long time before anyone notices. If the workflow is mission-critical (revenue contracts, hiring offers, vendor onboarding), you need HMAC verification, replay protection, idempotency keys, structured logging, and alerting. That is not a weekend build. It is an ongoing investment.

A 3-year cost model

Here is the model we walk customers through. Numbers will vary by region and team, but the shape holds.

Custom build, in-house (one mid-complexity Extension App + webhook relay):

Research on integration TCO is consistent with this: initial development is only 30-40% of the total cost of ownership; maintenance, updates, and adaptations are the rest. Most internal estimates we see capture only the first slice.

SI-led build:

The failure mode here is the SI ships the build, the retainer ends, and the integration becomes orphaned code that no one on staff fully understands.

Buy a focused product (e.g., a relay like Baton + native IAM connectors):

This is also where the IAM plan allowances matter. IAM is sold per user with feature allowances like Automation Sends per user per year, so the platform cost is mostly a fixed line item regardless of build vs buy. The variable cost is the integration layer on top.

The gap is not subtle. The question is whether the build delivers business value the buy cannot. Sometimes it does. Often it does not.

Where Workflow Builder draws the natural line

The cleanest pattern we have seen across IAM rollouts:

• Below Workflow Builder: buy. Connectors, relays, identity, payments, AI extraction (this is what Iris is for inside Agreement Manager). Anything that is plumbing.
• Inside Workflow Builder: configure. Routing rules, approvals, branching, data capture. No code.
• Above Workflow Builder: build, but selectively. Custom dashboards, internal tooling that wraps the workflow, AI agents that act on signed agreements. This is where in-house engineering creates leverage.

If you are building below the Workflow Builder line, you are usually rebuilding plumbing that someone else has already solved. If you are buying above the line, you are paying a vendor to ship a generic version of something your business actually needs to be specific.

For more on why we treat IAM as the spine rather than a CLM replacement, see Docusign IAM vs Traditional CLM.

Decision matrix by team size and use case

Team profile	Use case	Recommendation
<50 employees, no dedicated platform team	Trigger Docusign from CRM	Buy (native connector or relay)
<50 employees	AI clause review on signed contracts	Buy (Iris/Agreement Manager or vertical SaaS)
50-500, small platform team	CRM to Workflow Builder with custom field logic	Buy relay, configure in Workflow Builder
50-500	Industry-specific approval workflow	Build a thin custom step in Workflow Builder
500+, mature platform team	Internal system of record integration	Build, but only the proprietary parts
500+	Revenue-critical workflows across 5+ source systems	Buy the relay layer, build the business logic above it
Any size	Identity verification, payments, address lookup	Buy (App Center extensions)

The pattern: build where you are differentiated, buy where you are not. The mistake is conflating "we are technically capable of building this" with "we should."

When to revisit the decision

Build vs buy is not a one-time call. Revisit it when:

• Docusign ships a new native connector that overlaps with something you built. Migrate. Internal connectors are dead weight the moment a supported equivalent exists.
• Your maintenance load on a custom integration crosses ~20% of an engineer's time for two consecutive quarters. That is the threshold where buying becomes obviously cheaper.
• A workflow becomes mission-critical that started as a side project. The reliability bar moves; the integration that was "good enough" no longer is. This is the most common trigger for replacing a homegrown webhook listener with a purpose-built relay.
• You hit a Docusign API change that breaks your integration. Use the forced refactor as a chance to ask whether the rebuild is worth doing in-house.
• Your team composition changes. A platform team that loses its senior IAM engineer should buy. A team that just hired one might be ready to bring something back in-house.

For the financial side of this conversation (what the workflow itself is worth once it works), our ROI of Docusign Agreement Automation walkthrough is the companion piece. And if the specific question you keep landing on is "how do I trigger Workflow Builder reliably from my source systems," we wrote How to Trigger Workflows From Any Platform for exactly that.

The short version: build the things that make your business different. Buy the plumbing. Let Workflow Builder draw the line between the two.