Filament Autograph Laravel Package

Product Decisions This Supports

• Build vs. buy for signature capture. The field looks trivial — it's a canvas — but the real cost sits in pointer/touch handling across mobile browsers, image encoding, validation, model binding, clear/reset semantics, and re-testing everything on each Filament major upgrade. This package converts a 2–5 day build plus perpetual maintenance into a composer require. Default posture: buy, wrap it, move on.

• Closing "signature required" gaps in workflows you already own. This is a shipping accelerator for capabilities that keep appearing on the roadmap but never justify a sprint: consent and waiver capture, onboarding acknowledgements, internal approval sign-off, proof-of-delivery and technician completion, customer acceptance on service tickets, policy acknowledgement records. Each is days of work, not a quarter.

• Roadmap sequencing. Treat this as an enabler, not a differentiator. It lets you bolt a signature gate onto a resource that already exists, which is useful for clearing compliance-adjacent checklist items or unblocking a sales commitment without carving out dedicated engineering time. It should not appear on a roadmap as a line item — it appears as an enabler inside someone else's line item.

• A data-model decision you must make at the same time. The package supplies the field, not the evidence. A defensible signature record needs the image plus signer identity, timestamp, IP/user agent, document version, consent text, and an immutable audit trail. Adopting this package should be bundled with an explicit decision on where that metadata lives, who can view it, and how long it's retained. Skipping that step is how you end up with a folder of PNGs that prove nothing.

• Storage architecture as a product-level choice. Base64-in-a-column versus disk-path-in-a-column is not a purely technical call — it affects request size limits, table bloat, backup cost, retention enforcement, and whether you can ever cleanly migrate to a real e-sign vendor. Make the disk-plus-path call explicitly, up front, as a platform decision.

• Portfolio posture on Filament community plugins. Choosing a composable community field over a bespoke in-house form-field library is a repeatable policy, not a one-off. This is a cheap, reversible test case for whether that posture works for your team before you apply it to something that actually hurts to unwind.

• Prioritization input. 82 stars, zero dependents, single maintainer, MIT. Weigh it as a low-risk tactical dependency — cheap to adopt, cheap to abandon — not as infrastructure with a support contract. It should not enter a risk register at the same weight as a payments or auth dependency.

• Roadmap de-risking for customer-facing contracts. Explicitly scoping this to internal and low-stakes signatures lets you ship the internal use cases now while keeping the regulated, customer-facing agreements on the existing e-signature vendor. Two tiers, two tools, no ambiguity about which one carries legal weight.

When to Consider This Package

Adopt when:

• The product is already a Filament back-office/admin app and the signature is one field among many on a form you already have.
• The signature is internal or low-stakes: acknowledgements, internal approvals, delivery confirmation, onboarding paperwork — anywhere a captured image plus your own audit metadata satisfies the business requirement.
• Timeline pressure is real and a one-day spike beats a one-week build.
• You can pin the version, verify Filament major-version compatibility in a branch, and accept that you may vendor or fork the field later.
• The field is additive and reversible: nullable column or a disk path, one form, feature-flagged against whatever signature method you use today.

Look elsewhere when:

• The signature must be legally enforceable (ESIGN, eIDAS, industry regulation). That requires identity verification, tamper-evident sealing, consent records, and long-term audit trails — use a dedicated e-signature vendor and treat this package as, at most, a UI convenience.
• You need signatures placed onto a PDF at defined coordinates, multi-signer routing, or reminder/expiry workflows. That's a document workflow problem, not a form field.
• You're not on Filament — or you're on Livewire outside Filament. Integrate the underlying JS signature library directly rather than pulling in a framework-specific wrapper.
• Requirements include biometric/pressure data, handwriting recognition, or signature comparison.
• Organizational policy blocks low-adoption dependencies (small star count, no dependents, no vendor SLA) for anything touching regulated records.
• Mobile capture quality is business-critical and unvalidated — test on the actual devices your field staff carry before committing.

Verify before committing: supported Filament versions declared and exercised in CI; output format (raster vs. vector) and how it interacts with your storage disk and retention policy; whether capture routes through Livewire temporary uploads or rides base64 through component state; empty-canvas validation; asset publishing and CSP implications; accessibility fallback; maintainer responsiveness. The published release date (2026-10-08) should be sanity-checked against actual tags before you treat it as a liveness signal.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT-licensed) UI component that adds a signature-capture field to admin forms we already have. It turns a multi-day build into roughly a day of integration. It is aimed squarely at internal and low-risk signatures — acknowledgements, approvals, proof of delivery — not at replacing a legally binding e-signature service, which we'd keep for customer-facing contracts. Cost of reversal is near zero: it's a thin wrapper we could fork, swap, or remove without touching our data model. Recommendation: adopt now for internal use cases, keep regulated agreements on the existing e-sign vendor.

For engineering: It's a thin Filament form field wrapping a standard JavaScript signature pad — canvas in, image data out. We still own everything that matters: storage disk and file naming, validation, retention, and the audit metadata (signer, timestamp, IP, document version) that makes a signature usable as evidence. Low blast radius, MIT licensed, no transitive ecosystem to inherit. Ask for: a one-day spike on our exact Laravel/Filament/Livewire versions, confirmation that it renders and saves on real mobile devices, a pinned version, disk-plus-path over base64-in-column, and a thin wrapper class so a fork stays a one-file change.

For the delivery team: The technical work is small. The real work is organizational — agreeing on consent language, retention window, view access, and whether a PNG of a scribble actually satisfies the business requirement. Settle that before the pilot, not after.