Every B2B SaaS product eventually runs into a contract, and thus e-signatures. Onboarding agreements, order forms, NDAs, whatever it is, the moment arrives and someone on the team says “how hard can it be to just build this ourselves?” On the whiteboard it looks like a two-week project: render a PDF, drop in a signature box, save the file.
Then someone actually starts building it, and two weeks turns into two quarters.
Key Takeaways
- Building an in-house e-signature system often takes much longer than expected and requires ongoing maintenance.
- Legal compliance varies across jurisdictions, adding complexity to any in-house solution.
- Using established providers for e-signatures, like Firma.dev, can be more cost-effective than building your own system.
- Companies must consider the opportunity cost of engineering resources when deciding to build an e-signature solution.
- Most SaaS teams should compare costs: API provider fees versus the long-term commitment of building and maintaining it themselves.
Table of contents
What the whiteboard version misses for e-signatures
A signature flow that actually holds up needs a lot more than a drawing pad. Documents have to render the same way on a phone as they do on a laptop. Fields need placement and validation. If a deal has two signers, the second one shouldn’t get the e-signature document until the first one’s done. People ignore the first email nine times out of ten, so you need reminders that actually fire. And every finished document needs a tamper-proof seal and a full audit trail: who viewed it, who signed it, when, from where, kept somewhere you can pull it back up years later if anyone ever asks.
Then there’s the legal side, which is where most in-house builds really slow down. In the US, electronic signatures fall under the ESIGN Act and UETA, both of which have specific requirements around consent and record-keeping. The EU works differently again, with eIDAS defining a few different tiers of signature, each with its own evidentiary bar. Sell into more than one country and you’re now tracking rules in multiple jurisdictions, and those rules don’t stay still.
None of this is impossible to build. It’s just a lot more than the whiteboard version, and it keeps needing attention long after launch. A browser update breaks the field editor, a reminder job silently stops firing for signers in one timezone, and every big customer’s legal team wants to ask questions about your retention policy.
The bigger cost is what else those engineers could’ve shipped
The estimate never accounts for what the team gives up to build this. A couple quarters of senior engineering time goes into a feature that customers expect to just work and barely notice when it does. And it doesn’t stop after launch: every security review and compliance questionnaire from here on now has to cover a signing system you built and now own forever.
This already happened to other categories
Nobody really debates building their own payment processing anymore. Stripe settled that argument years ago. Twilio did the same for SMS and calls. E-signatures are going through the same shift, just later.
The pricing shifted with it. The big legacy providers still price signing like enterprise software: per-seat licenses, annual contracts, minimums that punish you for growing. Newer providers sell it as pay-as-you-go infrastructure instead. Firma.dev, for example, runs an e-signature API at €0.049 per envelope (~5¢ USD), no seats, no monthly minimum, signatures valid in 55+ countries. The signing editor embeds right into your own product, so customers never leave your UI, and you can usually get a working integration live in an afternoon. If you sell into Europe, it also runs on EU infrastructure, which tends to shorten the GDPR conversation with security-conscious buyers.
Run the numbers at that price and building it yourself stops looking like the safe choice. A company sending 10,000 envelopes a year is looking at roughly €490 (~$500) in API costs. That’s about a day of one engineer’s salary, for a whole year of signing.
When it’s still worth building for e-signatures
There are very few real exceptions .. its like building your own payment stack rather than hiring Stripe. For most SaaS teams, it’s worth putting two numbers side by side before anyone opens an editor: the invoice you’d pay an API provider this year, and the engineering time, ongoing maintenance, and compliance headaches you’d be signing up for instead.
