Should I vibe code
Fill, annotate, request low-stakes signatures, and track document versions
An e-signature is not a picture of a squiggle. It's the audit trail you'll be asked for two years later.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Split this in half and each half has an obvious answer. Filling and annotating a PDF is a solved library problem and a genuinely satisfying weekend. Asking somebody else to sign one is not a PDF problem at all — it is an evidence problem. What makes a signature survive 'I never agreed to that' is the record around it: who opened the link, from where, what they were shown, and a hash proving the file has not moved since. Drawing a squiggle onto a page is the part your agent will nail and the part that matters least.
What actually breaks
not "if". the specific failures.
- The audit trail you did not record. A signature is disputed two years later and you have a name, an email, a timestamp column and no way to show the document is the one that was signed
- Document integrity. Nothing stops the file being edited after signing unless you hashed it at the moment of signing and put the hash somewhere you cannot quietly change
- The signing link — a tokenised URL that opens a contract for whoever holds it. Sequential ids, no expiry, and it lives forever in a forwarded email thread
- PDF form fields, which render differently in Acrobat, Preview and a browser viewer, so what the signer saw is not necessarily what you stored
- Flattening. An unflattened filled form is still editable, so the signer's copy and your copy can disagree and both look genuine
- Redaction that draws a black rectangle over text instead of removing it, producing a document that publishes secrets while appearing to hide them
A contractor disputes the scope in an agreement they signed through your tool eighteen months ago. Your lawyer asks for the audit trail. What you have is a row in Postgres with a name, an email and a timestamp, and a PDF in object storage whose last-modified date is four months after the signature, because that is when you ran the script that regenerated every preview. Nothing was tampered with. You simply have no way to demonstrate that, and the job of showing the record is reliable has just become yours.
Is that you?
the verdict is a default, not a law
- It fills and annotates PDFs and never asks anyone else to sign anything
- Signatures are internal, low-stakes, and nobody would ever bother disputing one
- It runs locally over documents you already hold
- A signed document could ever be worth arguing about
- The documents carry tax identifiers, bank details or health information
- Signing links have no expiry and no per-recipient identity
- You cannot produce, today, a tamper-evident record of what a given person was shown and agreed to
If you build it anyway
the checklist, then the prompt that enforces it
- Separate the two products in your own head and build the boring one. Fill, annotate, merge, split, redact — all libraries, all local, none of it taking on somebody else's legal exposure.
- If you must do signatures, write the audit record before you build the signing UI: document hash before and after, signer identity and how it was established, IP, user agent, a timestamp from a source you do not control, and every view event.
- Hash the document with SHA-256 at signing and store that hash somewhere append-only. Without it, 'this is the document they signed' is an assertion rather than evidence.
- Flatten on signing. An unflattened form is an editable document with a picture of a signature on it.
- Signing links get high-entropy tokens, single use, an expiry, and an identity check that is not merely 'holds the link'. A forwarded email should not be able to sign your contract.
- Redaction means removing content from the PDF, not covering it. Test by copying text out of your own output before you believe it works.
I want a tool that fills and annotates PDFs, and eventually requests signatures. Treat signing as a separate, dangerous product and hold these lines.
1. Build the editing half completely first — fill, annotate, merge, split,
flatten — with no signature request flow at all. Tell me when that half is
done and make me ask for the second half explicitly.
2. Implement redaction as true content removal from the PDF content stream,
never a drawn rectangle, and add a test that extracts text from the output
and asserts the redacted string is gone.
3. Before any signing UI exists, design the audit record and show it to me:
document SHA-256 before and after signing, signer identity and how it was
verified, IP, user agent, timestamps from a source I do not control, and
every view, open and decline event.
4. Store the pre-signature and post-signature hashes in an append-only table.
Explain that without them, I cannot later show the file has not changed —
which is the failure I care about most.
5. Flatten form fields and signature annotations into page content at signing.
An unflattened signed form is still editable.
6. Signing links use at least 128 bits of entropy from a CSPRNG, are single
use, expire, and are bound to one recipient. Never sequential ids, never a
link that stays valid after signing.
7. Serve documents through an authorising handler, never from a public bucket
URL. Preview images are documents too.
8. Regenerate nothing after signing. If a preview or thumbnail pipeline would
ever rewrite a stored file, refuse, because it destroys the integrity
argument I am relying on.
9. Record what the signer was actually shown — the exact rendered document
version — not just which record they signed.
10. Build the evidence bundle export before launch: signed PDF, audit trail
and hashes, as files, per envelope.
11. Say in the README that this is not a compliance product, and that if a
signature will ever matter I should buy one already tested in a dispute.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The moment a signature could matter to anybody. Around $14 a month buys not an editor but an audit trail somebody has already had to defend, the ESIGN and UETA work you would otherwise be doing yourself, and tamper-evidence you did not have to design. Stirling PDF covers the entire editing half for free and self-hosted, which is the half worth owning.
$14/mo is cheaper than your weekend.
Export the artefacts, not the rows: per envelope, the signed PDF, the audit trail as its own file, and the document hashes. If a future dispute will be argued from a bundle, that bundle should already exist as files on disk rather than as a query against a database you may no longer be running.
Very active open-source, self-hostable toolkit covering the broad set of PDF operations — the safe half of this product.
Questions
Are the signatures my app produces legally binding?
Under ESIGN and UETA in the US, and eIDAS in the EU, a signature is not invalid merely because it is electronic — so 'binding' is rarely the interesting question. The interesting question is evidentiary: can you show who signed, that they intended to, that they were provided the record, and that the document has not changed since? That is an engineering problem, and it is the one that gets skipped.
Isn't the editing half genuinely safe?
Yes, and it is a good project. Filling, merging, splitting and annotating are library calls with a UI, they run locally, and the worst outcome is a corrupted file you regenerate. One caveat with teeth: redaction. If your redact draws a rectangle rather than removing the underlying text, you have built a tool that leaks secrets while looking like it hides them.
What is the minimum audit trail worth having?
Document hash before and after signing, in append-only storage; signer identity and how it was established; IP and user agent; timestamps from a source you do not control; and every view and open event. If that list feels like more work than the signing UI, that is the correct impression, and it is the reason this costs money.
- ESIGN Act — 15 U.S.C. § 7001, validity of electronic records and signatures (US)
- eIDAS Regulation (EU) No 910/2014 — electronic identification and trust services
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
PDF is a format that hates you. Annotation is fine; editing is where it fights back.
The best reason to self-host PDF tools: your documents stop being uploaded to strangers.
Merge and compress are library calls. "Sign" is a legal instrument, and yours is a picture of a squiggle.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice