Product Decisions This Supports
- Build vs. buy for capture-style inputs. A sketchpad field is a small, well-bounded piece of UI (canvas + touch/mouse handling + serialization + validation). This package is a candidate to adopt in hours instead of building and maintaining a custom Alpine/Canvas field over several days. The decision it informs: do we spend engineering time on a differentiated feature, or on commodity form input?
- Roadmap scoping for signature / proof-of-work flows. Directly enables or de-risks features like customer sign-off at delivery, on-site job completion acknowledgement, consent/waiver capture, inspection checklists with a quick diagram, or "mark up the floor plan" style annotation. If those live on the roadmap, this is a cheap way to prototype the interaction before committing to a spec.
- MVP and internal-tool acceleration. For Laravel teams already on Filament for admin panels and back-office tooling, this is a low-ceremony addition to an existing stack — no new frontend framework, no new vendor relationship. Relevant to internal tools, ops dashboards, and field-service back ends where polish is secondary to shipping.
- Scope boundary on e-signature. The decision to not treat this as a legal e-signature solution (audit trails, signer identity, tamper evidence, certificates of completion, retention policy). It captures a drawing; compliance-grade signing is a separate buy decision. Making that boundary explicit early prevents a costly scope surprise in legal review.
- Dependency posture. At 18 stars, 0 dependents, and a single maintainer, the decision this informs is "adopt as a thin, forkable convenience" rather than "standardize on it." MIT licensing means the fallback (vendor the code or fork) is cheap — a genuine risk mitigant worth stating in the ADR.
When to Consider This Package
Consider it when most of the following hold:
- You are already running Filament (and a compatible major version — confirm the supported Filament/PHP matrix before committing; a field package is tightly coupled to the form API).
- The need is a freehand drawing capture — signature, initials, a quick diagram, an annotate-this-image interaction — stored as part of a form submission.
- You need "good enough" fidelity, not pressure sensitivity, vector export, stroke replay, or layered editing.
- You are comfortable with a single-maintainer, low-adoption dependency and have a stated fallback: pin the version, vendor the source, or fork under MIT.
- You have verified the practical unknowns: output format (base64 payload vs. uploaded file), how it is persisted and served, mobile/touch behavior, image size and validation limits, dark-mode/RTL handling, and whether it plays well with Filament's file uploads and policies.
- The workflow tolerates a canvas-rendered image as the artifact (e.g., attached to a record as evidence), rather than requiring structured or machine-readable data.
Look elsewhere when:
- You need legally defensible e-signature — audit trail, timestamps, signer authentication, tamper evidence. Buy a dedicated e-signature product; do not build compliance on a canvas field.
- You need vector output, stroke data, or editable annotations downstream.
- Your Filament version is outside the supported range, or you are not on Filament at all — the value is entirely in the field integration.
- Your dependency policy disallows low-adoption, single-maintainer packages in production paths. In that case, budget 1–3 engineering days to build the equivalent (a canvas component wrapped as a Filament field) rather than fighting the policy.
- Signing/consent is core to the product rather than a supporting detail — then the interaction deserves a designed, owned implementation.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed UI component that adds a drawing/signature box to our existing admin and ops screens. The business case is speed: it lets us prototype and ship sign-off, consent, and proof-of-delivery flows in days rather than weeks, using the Laravel/Filament stack we already run — no new vendor, no new platform, negligible cost. It is deliberately not a legal e-signature system; if we pursue regulated signing, that remains a separate, properly scoped purchase. Risk is contained: the code is open and forkable, so worst case we own a small component we would otherwise have written ourselves. Recommendation: approve a short time-boxed spike in a non-critical flow, with a go/no-go on fit, mobile behavior, and data handling.
To engineering: A Filament form field wrapping a canvas sketchpad — the value is that it removes the boilerplate of building touch/mouse capture, serialization, and Filament field plumbing ourselves. Three things to confirm in the spike: (1) Filament/PHP version compatibility and upgrade exposure, (2) what it actually emits and how we persist and serve it (size limits, storage disk, validation, cleanup), (3) touch/mobile and accessibility behavior, since a canvas input is inherently weak for keyboard users — plan a fallback (e.g., upload an image) where the flow is customer-facing. Assume single-maintainer risk: pin the version, read the source (it should be small), and be ready to vendor or fork. If the spike shows friction, the build is a bounded 1–3 day task and we keep full control.