Best of luck. I think you need to answer two questions -- (i) how would you compete/compare against the likes of documenso.com and (ii) the usual legalities - authoritativeness, acceptance, etc.
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.
Currently the documents are signed with PKCS#1 signature, signed documents can be verified at https://demo.docuseal.co/settings/esign (to ensure that they were produced by the tool and not altered/forged by some third party). Additionally I'm planning to add a merkle-based log of documents to ensure that documents were not altered by the party that is self-hosting the tool.
I think that's a valid point - and actually in their terms of services say that they are not responsible for the signer authenticity.
Here is a summary from their TOS:
"DocuSign provides tools and features that help to establish the authenticity of a signer, such as email verification, access code, SMS verification, phone verification, and knowledge-based authentication. However, it's important to note that while these tools can enhance the security and authenticity of the signing process, DocuSign itself does not guarantee the authenticity of the signers. The responsibility of ensuring the identity of the other party lies with the user"
can you please elaborate which use-cases? - maybe that's something that actually can be possible by splitting some parts of the project into MIT licensed dependencies?
I'm thinking of cases where the pdf is accessed over a network. Like integrations with systems that do billing, invoicing, taxes, tickets to a game, rent receipts, pulling pdfs from your email, pulling pdfs from S3, almost everything?
That's interesting that you ended up developing an in-house document e-signing feature for your product. I'm curious, would it be possible for you to choose a self-hosted and open-source solution like Docuseal, integrated with your product to outsource the complexity and speed up the development? (if such an option existed back then?)
Honestly the bulk of complexity seemed to emerge from the mismatch between what we thought would be a good e-sign API and what APIs were actually available.
The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.
We also needed a way to in-line bank-specific e-sign consent documents into the experience, giving the e-signer a way to decline consent and have this decline kick off an appropriate back-office workflow. The other reason we went in house is we wanted to completely close the loop. After the last e-signer completes their piece, our product detects this condition and submits all final documents to the institution's long-term cold storage system. Getting this to work with a 3rd party API looked like a total non-starter to me - We can't just send the docs right away. There are time-of-day constraints on when those systems will be available throughout the week.
Our e-sign solution ultimately turned into a workflow-style experience with 6-7 steps.
> The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.
Can you elaborate on this? Why people would want to have the signature first before showing the document?
In our solution, providing the up-front signature does not construe immediate consent to terms of whatever hypothetical documents. We have a subsequent review phase where the customer is expected to confirm each document meets their expectations (i.e. with their actual signature on it). Only after confirming all of the documents is the transaction considered to be completed and the signed copies taken as official.
The more complicated answer is that we are serving e-signatures for business accounts wherein there might be 10+ authorized signers involved. In these cases, we want to permit parallel sign completion. To allow this, each signer gets to view an isolated scope of documents with just their signature affixed. This also helps to conceal the signature specimens of other parties until the entire transaction is considered finalized. If a required party to an account does not want to participate, then no one gets to see anyone else's ink.
At the very end, all participants of the signing ceremony receive emailed copy of documents that combine signatures from all participants.
> Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant.
Why would I sign something I haven't seen?
Businesses & government in USA seems to like asking for my signature on a little LCD pad, without showing me what I'm signing. That's absolutely horrible and anti-consumer behavior.
(And yes, I do diff DocuSign-style PDFs before and after the insertion of the pseudosignatures and visible watermarks, or PDFs from before and after a email-print-sign-scan-email cycle.)
