DocLatch

Overview

Admins create documents, upload PDFs and generate a link per signer. Signers review the PDF and either submit a signature or decline. Every step is recorded, and signing on a phone is treated as the main case rather than an afterthought.

The problem

Community organisations often need a signature on a document from people who are not on any platform, many of them on a phone and some in another language. The commercial tools are priced and designed for businesses.

The approach

A server-driven design in which the server, not the browser, is the source of truth. Each signer gets a single-use link, a signature is stored as an immutable record rather than overwritten, and every lifecycle state (pending, signed, declined) and every event is explicit and logged. Documents can carry additional-language versions, and signing was designed and tested for iOS Safari first.

Outcome

• A complete flow from document creation to a finalised, downloadable PDF with each signer's signature as a transparent PNG
• Signed URLs for PDF previews are short-lived, and signer links are one-time with regeneration available to the admin
• Firestore and Storage rules, a changelog and a security note are kept in the repository

What it does

• Immutable signatures

  A signature is a record that can be voided but not edited, so the history of who signed what, and when, cannot be quietly rewritten.

• One link per signer

  Links are single-use and expire, and the admin can regenerate one without disturbing the others.

• Languages beyond English

  A required English PDF plus optional Nepali, Spanish, Hindi or custom-code versions, each with its own file.

• Decline is a first-class answer

  A signer can decline, and the status shows it, instead of the document sitting silently pending.