How to Build an App Like DocuSign (E-Signature Platform)

DocuSign charges $45 per user per month on its Standard plan and $65 per user per month on Business Pro. A 25-person team on Business Pro pays $1,625 per month, or $19,500 per year. For a company that routes documents through its own software, that number grows faster than the user count. Each new workflow, each new integration, each new envelope type sends you back to DocuSign's pricing page.

This article covers what it takes to build an e-signature platform like DocuSign, which components are harder than they look, and when the build math actually makes sense.

What a DocuSign-like platform actually means to build

DocuSign is four things: a document storage system, a field placement editor, a signing workflow engine, and a legal evidence package. The fourth one is the one most developers underestimate.

The document storage system holds the original PDF, the configured fields, and the completed document. Each lives in a separate state. The original never changes. The completed document includes embedded signatures, a full audit log, and a certificate of completion.

The field placement editor is the visual drag-and-drop layer where senders position signature fields, initials fields, date fields, and text fields on specific pages. This sounds straightforward. The challenge is coordinate-based field positioning: every field is stored as a percentage offset from the page's top-left corner, not as pixel coordinates. This is required because the same document renders at different sizes on different screens and in the final PDF. Pixel coordinates break. Percentage offsets stay stable.

The signing workflow engine manages the envelope: who signs, in what order, what notifications go out, when reminders fire, and what happens when the last signer completes the document. Signers never log in. They receive a unique, JWT-authenticated link that grants access to their specific fields for a limited time. The token expires. The session is stateless.

The legal evidence package is the audit trail plus the certificate of completion. Without it, the signature is legally fragile. With it, the signature is as enforceable as a paper signature in jurisdictions that recognize ESIGN and UETA (the two U.S. laws governing electronic signatures).

Core features to build (MVP vs. full)

MVP: upload, place, sign, complete

The minimum viable e-signature build covers four stages end to end.

Document upload and rendering starts with a PDF. The user uploads it, the system stores it in S3, and the frontend renders each page as a canvas element. PDF.js handles client-side rendering. The rendered pages are what the field placement editor works on.

Field placement is a drag-and-drop editor built on top of the rendered pages. Four field types cover 95% of use cases: signature (a drawn or typed name rendered as a styled string), initials, date (auto-populated on signing), and text (free-form input). Each field stores its page number, its x/y offset as a percentage of page dimensions, and its width and height. This data goes into PostgreSQL alongside the envelope record.

Signing workflow sends each signer a unique link. The link encodes the envelope ID and the signer ID in a JWT signed with your server secret. The signer clicks the link, sees only their assigned fields, completes them, and submits. The backend verifies the JWT, records the completion event, and checks whether all signers have finished. When the last signer completes, the workflow moves to the finalization stage.

Completed PDF generation is where PDF-lib does the real work. It opens the original PDF, overlays each signature and field value at the stored coordinates, appends a certificate of completion page with the full audit log, and writes the final document. The final PDF is immutable. It goes back to S3 under a new key. The original is preserved separately.

Full build: templates, bulk sending, and reminders

Templates allow senders to define field positions once and reuse them across many documents of the same type. An NDA template, a vendor agreement template, an offer letter template. The template stores the field positions and the signer role definitions. Senders apply a template to a new document and fill in the signer email addresses.

Bulk sending creates envelopes from a template for a list of recipients. Upload a CSV of names and emails, and the platform creates one envelope per row, each with the correct signer link. This is what makes e-signature viable for high-volume workflows: sending 500 NDAs for a conference or 200 offer letters at the end of a hiring cycle.

Reminders fire automatically at configurable intervals. A signer who has not completed within 48 hours gets a nudge email. At 7 days, a second reminder. At 14 days, the sender gets a notification that the envelope is stale. This is not complex logic, but it requires a job scheduler. Redis with Bull handles the deferred jobs. SendGrid delivers the emails.

Audit trail viewing gives senders a full timeline for any envelope: when each signer opened the document, when they completed each field, when the envelope finalized, and the IP and device type for each event.

The tech stack

The API runs on Node.js. It handles envelope creation, signer token generation, field storage, audit event recording, and the completion pipeline. Every operation that touches a document goes through the API. Nothing writes to S3 or the database from the frontend directly.

PostgreSQL holds three primary tables: envelopes (status, sender, created/completed timestamps), signer records (name, email, status, JWT token hash), and audit events (event type, timestamp, IP, user agent, and the hash chain fields).

AWS S3 stores three document versions for each envelope: the original PDF, the field overlay JSON (a snapshot of field positions at the time of sending), and the completed PDF once finalized. S3 versioning is enabled. Documents are never deleted. A retention policy moves old documents to Glacier after 7 years.

PDF-lib is the library that actually writes signatures into PDFs. It supports adding text, images, and custom fonts to existing PDF pages at specific coordinates. The signature itself is drawn on an HTML canvas element during signing, exported as a PNG, and embedded into the PDF at the stored coordinates using PDF-lib. Initials follow the same pattern. Typed signatures use a handwriting-style web font rendered as a PNG before embedding.

JWT tokens authenticate signers. Each signer gets a unique token that encodes the envelope ID, signer ID, and expiration time. The backend signs it with a 256-bit secret. Tokens expire after 30 days by default. If a token expires before signing, the sender can resend a new link. Tokens are one-time-use: once a signing session completes, the token is invalidated.

SendGrid handles all transactional emails: the initial signing invitation, completion notifications to the sender, reminders, and the final completed document delivery to all parties.

Redis manages active signing sessions and the job queue for reminders and scheduled notifications.

How long it takes and what it costs

A full e-signature platform runs $60,000–$100,000 over 10–14 weeks.

An MVP covering upload, field placement, basic signing workflow, and completed PDF (without templates or bulk sending) runs $40,000–$65,000 over 7–9 weeks. That is enough for a closed beta with real documents.

The two hardest technical problems

Tamper-evident audit trail with hash chaining

The audit trail is not just a log table. It is a cryptographic evidence chain. The distinction matters because a log table can be altered without detection. A hash-chained audit trail cannot.

Here is how it works. Every event in the signing lifecycle gets a record: envelope created, invitation sent, document opened, field completed, signature captured, envelope finalized. Each record includes the event type, the timestamp, the actor's IP address, the user agent string, and a SHA-256 hash of the record's own content fields.

The chain hash is the piece that creates tamper evidence. Each event record stores the hash of the previous event record. The first event has no previous hash (it stores a fixed sentinel value). Every subsequent event includes the prior event's hash in its own record before computing its own hash.

The result: if anyone deletes or modifies a record in the middle of the sequence, every subsequent record's chain hash becomes invalid. The chain is broken. The tamper is detectable.

When the envelope finalizes, the system computes a root hash of the entire chain and embeds it in the certificate of completion. A legal reviewer can recompute the root hash from the stored events and verify it matches the certificate. This is the technical mechanism behind legal enforceability. Without it, the document is a PDF with an image of a signature. With it, the document is a legally defensible record.

Cross-device signature capture

A signature drawn with a mouse on a desktop, a stylus on an iPad, and a finger on an Android phone are three different input experiences. All three must produce a consistent, clean vector output embedded in the final PDF at the correct coordinates.

The technical approach uses an HTML canvas element with pointer events. The pointerdown, pointermove, and pointerup events work across mouse, touch, and stylus inputs. The drawing algorithm uses Bezier curve smoothing to convert raw pointer coordinates into a natural-looking signature stroke rather than a jagged line.

The canvas is then exported as a PNG at 2x resolution for retina displays. That PNG gets compressed and stored as a base64 string alongside the field record. During PDF generation, PDF-lib embeds the PNG at the field's stored coordinates, scaled to the field's stored dimensions.

Three failure modes to handle: very fast strokes where the pointermove events are sparse (solved with interpolation), very slow strokes where the curve smoothing overshoots (solved with adaptive tension on the Bezier control points), and low-memory devices where canvas operations are slow (solved with canvas size limits based on document resolution).

Build vs. DocuSign: when custom wins

DocuSign wins for: most companies. DocuSign's Personal plan at $15/month covers basic signing. The Standard plan at $45/user/month covers team workflows, templates, and integrations. For a company that just needs to send contracts for signature, DocuSign's infrastructure is mature, its legal standing is established, and the per-seat cost is straightforward.

Custom wins for:

High-volume document operations. DocuSign's envelope pricing adds up. The Business Pro plan charges per envelope above the plan allowance. A company processing 2,000 envelopes per month is paying for volume. At that scale, the build pays back in under 18 months and the per-document cost drops to essentially zero marginal cost.

HIPAA-regulated workflows. DocuSign offers a HIPAA-compliant product, but it requires a Business Associate Agreement and specific configuration. A healthcare company with specific PHI handling requirements, custom data residency requirements, or existing HIPAA infrastructure may need signing embedded in their own environment rather than routed through DocuSign's.

CLM and legal automation integration. Law firms and legal operations teams building client intake workflows or AI-assisted contract management often need the signing step embedded natively in their platform. A custom e-signature module that writes directly to the same database, triggers the same workflow engine, and stores documents in the same S3 bucket is far cleaner than a DocuSign webhook integration.

Vertical SaaS products. A platform built for real estate transactions, mortgage processing, insurance policy delivery, or HR onboarding can own the signing experience end to end. This improves the user experience, removes DocuSign branding, and allows the platform to capture the e-signature as a workflow event rather than a separate product.

How RaftLabs can help

RaftLabs has built document-heavy workflows for legal platforms, HR systems, and real estate tools. We know the PDF coordinate system, the audit trail architecture, and the places teams consistently underscope: the signature canvas rendering on mobile, the hash chain implementation, and the completed PDF assembly at scale.

Our typical Phase 1 engagement for an e-signature module (upload, placement, signing workflow, and audit trail) runs $40,000–$65,000 over 7–9 weeks. We start with a discovery sprint to map your document types, your signer flows, and your integration points, then produce a fixed-scope proposal.

If signing is a workflow step inside a product you are building, the build conversation is worth having before your next DocuSign renewal.