In this highly competetive market we're currently more focused on things that we can do better like on-premises and embedding/API.
DocuSeal doesn't require any significant initial costs to be built - and then it comes only to our ability to build a great product to come over the competitors.
Regarding the compliance we're focused on simple eIDAS signatures for the EU and also we follow the UETA and the ESIGN Act.
When comparing to Iframe our JS-based solution better adopts to the existing page layout due to the fact that it embeds into the existing page DOM (when iframe lives in it's own DOM which brings many limitations). Also it loads much faster than any equivalent iframe solution
Hi everyone, my name is Alex, and I'm the CTO and Founder at DocuSeal – an open-source alternative to DocuSign.
Recently, we launched DocuSeal Cloud, which is available in both the US and EU regions. Our goal is to create a developer-friendly document signing infrastructure, similar to how Stripe has revolutionized the payment infrastructure. The HTML API described in this blog post is the first step of this initiative. You can find more information about the developer tools at DocuSeal here: https://www.docuseal.co/integration.
Looking for some feedback and would be happy to answer any questions.
I mostly agree with the author. After working a couple of years with React client render and API a pure server render seems to be a way more productive. For my recent OSS project (https://github.com/docusealco/docuseal) I use server render everywhere except of the 2 most complex/dynamic UI parts (drag&drop form builder and the signing form). I think just figuring out which approach fits best for which part of the software is the most important thing, doing both SSR and CSR in a single project is completely fine when done right.