Documenso

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a document signing service that replaces a hosted Documenso: send a PDF, collect signatures, and seal the result so it can be proved later.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- pdf-lib for filling and stamping, and node-signpdf or an equivalent for the cryptographic signature
- Caddy in front

THE DATA MODEL
- documents: id, uid, title, owner_id, original_path, original_sha256, final_path, final_sha256, status, expires_at, created_at, completed_at
- recipients: id, document_id, name, email, role, order_index, token, viewed_at, signed_at, declined_at, decline_reason, auth_kind
- fields: id, document_id, recipient_id, kind, page, x, y, width, height, required, value, meta_json — signature, initials, name, date, text, checkbox, dropdown
- audit_events: id, document_id, recipient_id, kind, actor, ip_hash, user_agent_bucket, meta_json, at — append-only, and the most important table here
- templates: id, name, base_path, fields_json, roles_json
- certificates: id, kind, subject, not_before, not_after, key_path — the sealing certificate
- The original file is never modified. Every signature produces a new file, and the hash of both is recorded

THE AUDIT TRAIL, WHICH IS WHAT IS ACTUALLY BEING SOLD
- Every event recorded: created, sent, delivered, opened, viewed each page, field completed, signed, declined, downloaded, reminded, expired
- Each with a UTC timestamp, the actor, a salted hash of the address, and a coarse user agent
- Nothing in this table is ever updated or deleted, enforced by a trigger
- At completion the trail is rendered as a page appended to the finished PDF: who signed, when, from where, with the hash of the document they saw. A signature without that page is a picture of a name

SIGNING ORDER AND ROLES
- Recipients in parallel or in a set order, with the next one notified only when the previous has finished
- Roles: signer, approver, viewer, and a carbon copy who receives the finished document
- Each recipient gets a long random token in their link, compared in constant time. No account, ever — requiring one is how a signing request goes unanswered
- Optional extra authentication before signing: a code by email, or a passphrase the sender shares by another channel. Record which was used

PLACING FIELDS
- The document is rendered to images page by page for placement; fields are dragged onto it and stored in PDF coordinates, not screen pixels
- Required and optional fields, per recipient, with validation before submission
- Defaults and pre-filled values from the sender
- Templates: fields and roles saved once and reused, with the recipients filled in per send

SIGNING
- Draw with a pointer or a finger, type in a signature face, or upload an image
- The drawn signature is captured as a path and rasterised at print resolution, not screenshotted from the canvas at screen resolution
- Works on a phone, because most signatures are collected on one
- A clear review step showing every field before the final confirmation, and a decline path with a reason

SEALING
- On completion, flatten the fields into the PDF and apply a document-level digital signature with a certificate held on the server
- Any later change to the file breaks the signature, which is the point
- A long-term validation profile with a timestamp from an RFC 3161 authority, if one is configured, so the signature remains verifiable after the certificate expires
- Explain the honest position in the README: this proves the document has not changed since sealing and records who did what and when. Whether that satisfies a particular law in a particular country is a question for a lawyer, and the tool must not pretend otherwise

DELIVERY AND CHASING
- Emails for each stage, in plain text and HTML, with the link and nothing else
- Reminders on a schedule the sender sets, at most one per recipient per day
- Expiry, after which the link stops working and the document is marked expired
- The finished document sent to everyone, with the audit page attached

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SMTP_URL, SESSION_SECRET, HASH_SALT, SIGNING_CERT_PATH, TSA_URL
- Migrations on boot, each once
- Files encrypted at rest, keys from the environment
- Nightly backup covering the database and the file store, and a tested restore — losing a signed contract is not an outage, it is a loss
- Health endpoint that seals a one-page document

WHAT MATTERS MOST
The audit trail and the seal. Build the append-only events table, the appended certificate page and the signature verification first, then take a completed document, change one byte, and confirm the verification fails. Everything else is a form on top of a PDF.

Give me the repository, migrations, .env.example, a seed document with two signers in order, and a README with deploy steps behind Caddy, certificate generation, and the sentence about legal advice kept intact.