Bolt-On, Build, or Embed: The Platform eSignature Decision
Verdocs Team
There is a predictable moment in the life of a vertical SaaS platform. You have built something valuable for insurance carriers, or accounting firms, or lenders. Your customers use it every day. And then signatures become the bottleneck.
A policy cannot bind until it is signed. A loan cannot fund until it is signed. An engagement letter is not an engagement until it is signed. Signing sits directly on the critical path of the workflow your product exists to run, and yet for most platforms it is the one step that happens somewhere else.
So you have to decide how to solve it. There are three real answers, and the industry tends to discuss them as though the choice were mostly about price. It is not. The choice determines who owns your customer's experience, who captures the margin on a transaction your product generated, and whether what you ship survives a multi-tenant deployment at all.
The three paths
Integrate with a third-party eSignature product. You connect to an established vendor. Your user clicks a button, leaves your application for a signing experience carrying someone else's name, and comes back when it is done. This is fast to ship and cheap to start. For a platform with modest volume and no strong opinion about the signing experience, it is a reasonable answer, and it stays reasonable for a long time.
Build it yourself. You license a PDF toolkit and a certificate authority relationship, and you construct signing from primitives. You get total control. You also acquire a compliance surface, an audit trail, a tamper-evidence model, and an identity verification story, all of which now need engineers indefinitely. At extremely high volume the arithmetic can favor this. Below that, you have started a second company inside your company.
Embed signing infrastructure. You use a provider whose product is designed to disappear into yours: APIs, SDKs, and user interface components that render inside your application rather than beside it. Your users never leave. Your brand never leaves. You control the workflow, and you control what you charge for it.
Volume is a rough guide to which path fits. Below roughly 50,000 envelopes a year, a bolt-on integration is usually fine. Above several million, building may genuinely pay for itself. The wide middle, which is where most serious vertical platforms live, is where embedded infrastructure wins.
But volume is the least interesting part of this decision. Three other questions matter more.
Question one: who owns the experience?
This is the question that sounds like a branding concern and is actually a product concern.
When a user is pushed into a third-party signing experience, several things happen at once. Your carefully designed workflow acquires a seam. Your support team starts fielding questions about an interface they cannot see. Your conversion funnel develops a step you cannot instrument or optimize. And your customer learns that a critical part of the job is done by a company that is not you.
The important nuance is that "embedded" is not a binary, and the word is used loosely enough to be nearly meaningless in a sales conversation. Most major eSignature vendors will tell you they support embedded signing, and most of them do. What that generally means in practice is that their application is displayed inside a frame within your page. The user does not navigate away, which is a genuine improvement over a redirect, but the experience inside that frame is still the vendor's product. Your design system does not apply to it. Your team cannot change how it behaves.
The alternative is signing UI that runs as components inside your own front end, where your CSS reaches it and your developers control it. That distinction sounds academic until the first time a customer asks you to change something inside the signing step and the honest answer is that you cannot.
We wrote a detailed technical breakdown of this difference, including exactly what is and is not customizable in each model, for teams that want to evaluate it precisely.
Question two: who owns the economics?
Most eSignature pricing was designed for companies buying signing for their own employees. It is sold per seat, with an envelope allowance attached to each seat.
That model fits a platform badly. Your usage does not scale with your headcount; it scales with your customers' activity. If you are providing signing to thousands of downstream tenants, per-seat pricing is not merely expensive, it is structurally misaligned with how value moves through your business.
It also constrains what you can charge. Signing is a feature your customers will pay for, and many platforms want to package it into a tier or resell it. That only works if your own cost is predictable, usage-based, and low enough to leave a margin worth having.
There is a practical requirement hiding here that teams routinely discover late. If you resell signing, you have to know which of your tenants generated which envelopes, or you cannot bill them. That means your provider needs to model your customers as distinct organizations and meter them separately. It is unglamorous infrastructure, and it is the difference between reselling signing and merely absorbing its cost.
Question three: does it actually work multi-tenant?
Your platform serves many customers who must never see one another's data. Any component you embed has to respect that boundary.
This is where a number of embedded offerings quietly fail. A vendor may offer an embeddable view of document status or history, but scope it to the account rather than to a single document or tenant. In a single-company deployment that is fine. In a multi-tenant platform it is disqualifying, and it is the kind of thing you discover in week six of an integration rather than week one.
The right question to ask any provider is narrow and revealing: what exactly is the token scoped to? If the answer is a single document and a single participant, you can safely put that component in a browser. If the answer is the account, you cannot.
When a bolt-on integration is the right answer
It would be dishonest to write this and pretend the answer is always the same.
If signing is a peripheral convenience in your product rather than a step on the critical path, a standard integration is the correct engineering decision. If your volume is low, the economics never become painful enough to justify an architectural project. If your customers have specifically asked for a particular vendor by name because their legal team has already blessed it, give them that vendor. And if you need something live in a week, an integration will get you there and an embedded architecture will not.
The established vendors in this category are established for good reasons. They have deep compliance coverage, enormous brand trust, mature APIs, and in many markets a name that shortens your own sales cycle. Those are real assets, and for a large number of companies they outweigh everything discussed above.
The case for treating signing as infrastructure
The argument for embedding is not that other products are weak. It is that a platform and an end-user application want fundamentally different things from signing.
An end-user application wants signing to be a destination, with its own brand, its own login, and its own relationship with the signer. A platform wants signing to be invisible: a capability its product performs, in its own interface, on its own terms, billed on its own paper.
Those are different products, and the second one is what we build. Verdocs provides signing as infrastructure for software companies, delivered as APIs and native UI components that live inside your application rather than beside it, priced on envelope consumption rather than seats, and structured so you can meter and bill your own tenants.
Once signing becomes infrastructure inside a policy administration system or a lending platform, something durable happens. It stops being a vendor relationship and starts being part of how the product works. It expands across workflows and business units. And it becomes very difficult to replace, which is exactly what you want from something sitting on your critical path.
Evaluating embedded signing for your platform? We are glad to walk through the architecture with your engineering team, including an honest assessment of where a conventional integration would serve you better. Get in touch.
