Case study
The signature is the easy part. The evidence is the product.
Anyone can draw a name onto a PDF. What makes an e-signature worth anything is the record behind it: who signed, from where, when, having seen exactly which document — and the ability to prove none of it changed afterwards.
01 / The problem
What was actually hard.
A signing platform is a chain of custody problem wearing a document viewer. Every step — sent, opened, viewed, verified, signed, declined — has to be captured immutably and tied to the exact bytes of the document the signer saw. If the file can change after signature, or the audit trail can be edited, the whole artefact is worthless in a dispute.
PDF itself is the other difficulty. Field placement has to survive different page sizes, rotations and generators; signatures must be composited without corrupting the original; and none of it can block the web request while a large document is processed.
02 / What we built
The system.
- Envelopes, recipients and fields
- A document set sent to an ordered list of recipients, each with their own assigned fields — signature, initials, date, text and attachments.
- A signing flow designed around refusal
- Tokenised links with an identity verification step, the ability to decline with a reason, and per-recipient attachment upload — because 'no' is a legitimate outcome that most implementations handle badly.
- Certificate of completion and evidence pack
- A generated certificate plus a downloadable evidence bundle covering the full event history — the artefact that actually matters if the signature is ever challenged.
- An append-only audit trail
- Every event recorded as its own row rather than a mutable status column, so the history can be reconstructed and not quietly rewritten.
- Reusable templates
- Prepare a document once with its fields, then copy, share, replace the underlying file, or spawn an envelope from it.
- REST API with keys and webhooks
- Envelope create, send, void, certificate and evidence over an authenticated API, with webhook endpoints and recorded delivery attempts so a failed callback is visible rather than lost.
- A separate PDF engine
- Rendering and compositing run in their own Node service rather than in the web process, so a heavy document cannot block a request or take the application down.
03 / What carried over
Decisions worth reusing.
The parts of this build that we would apply again on a different problem in a different sector.
- Append-only beats a status column
- Anything that may be disputed later should be modelled as an immutable event log. Reconstructing history from a mutable field is not possible after the fact.
- Isolate the expensive work
- Document rendering belongs in its own process with its own failure domain. It is the component most likely to be slow, and the one you least want inline.
- Design for the unhappy path first
- Declines, expiries, wrong recipients and re-sends are the majority of real traffic in a signing product, and the part competitors handle worst.
04 / More work
Other builds.
Different sectors, the same delivery discipline.
Bits N Pixels
A software consultancy's site rebuilt as a platform — CMS, client portal, invoicing and multi-gateway payment links, with no CSS framework anywhere.
Encore Episode
A vertically-integrated event commerce platform — ticketing, gate control, cashless payments and vendor settlement in one system.
Property Marketplace
A verified-first property portal — listings that carry evidence, in-app messaging, and a shortlist and visit flow built around actual buyer behaviour.
Next step
Have something like this to build?
Start with a diagnostic. It is fixed-fee, time-boxed, and it will tell you honestly whether the thing is worth building — including when the answer is no.