Filament Docs Laravel Package

Product Decisions This Supports

• Build vs. buy for document generation. The decision on the table is whether to build a template-driven document/contract generator inside our admin panel or buy one. This package reframes that as "buy cheap, own the edges": MIT-licensed, composer-installable, two models (Document, DocumentTemplate), a plugin registration, and a print/PDF path — realistically a 1–2 day spike rather than a multi-sprint build. The buy decision is therefore low-regret, and the real build-vs-buy question narrows to the edges (signature, approvals, audit) which this package explicitly does not cover.
• Feature scoping for a v1. The package draws a clean line: it is document authoring and rendering, not document governance. That gives us a defensible v1 scope — "generate from template, inject variables, print/export PDF" — and an explicit, stakeholder-visible backlog of v2 items: e-signature, approval workflow, immutable version history, retention policy, document classification.
• Roadmap sequencing and dependency coupling. v5.0.0 targets Filament v5 + Laravel 12/13; the v3 line is separately maintained and Filament v4 appears to have no supported line. Adopting this turns "should we upgrade the admin stack to Filament v5?" from a background chore into a gating prerequisite on the roadmap. That sequencing decision needs to be made once, deliberately, not discovered during implementation.
• Use cases we can serve now. Customer-facing proposals and SOWs, letterheaded PDFs, per-account letters and notices, HR/onboarding letters, invoice-style documents, and any "pick a template, fill vars from this record, print" flow. The DocumentAction::make()->vars(...) pattern means generation is attachable to existing resources — a strong argument for shipping this as a feature inside workflows we already have rather than as a new destination product.
• Tenancy and data-isolation posture. Tenant scoping requires ->isScopedToTenant() plus migrations we write ourselves (team_id on both tables). That is a schema change and a correctness obligation we own — a product decision about whether this ships as single-tenant-only in v1 or carries the isolation work.
• Branding and white-label decisions. Header, footer, and print CSS are injectable via facade (FilamentDocs::header/footer/css) without forking. That means per-customer or per-brand document output is a configuration decision, not an engineering project — relevant if document appearance is part of a commercial promise.
• Prioritization signal against alternatives. 45 stars, 0 dependents, single maintainer: this is not a market-validated product choice, it's a cheap, forkable accelerator. That framing should push us toward "adopt behind an abstraction, plan to vendor" rather than "standardize the document platform on it."

When to Consider This Package

Consider it when most of these hold:

• We are on, or committed to, Filament v5 with Laravel 12/13 — the only actively supported line.
• The job to be done is "generate, print, and export", not "execute and govern." Internal letters, proposals, confirmations, statements, and non-binding documents are ideal.
• We want template authoring inside the admin panel, by non-engineers, with variables mapped declaratively from Eloquent records or globals.
• The team is small and would rather spend a sprint on differentiators than on a rich-text editor, variable interpolation, and print CSS.
• We are comfortable with a single-maintainer, low-adoption dependency — because the surface is small, the license is MIT, and the Blade views are publishable, so vendoring or forking is a credible fallback.
• We can absorb a 1–2 day spike to validate migrations, panel rendering, and — critically — real PDF output from a contract-shaped template, not a hello-world.

Look elsewhere (or budget to build) when any of these are true:

• We need e-signature, approval chains, immutable versioning, an audit trail, retention policy, or document classification. None of that is here; it is entirely ours to build, and if it's the core value, this package is the wrong foundation.
• The documents are legally or regulatorily load-bearing. The release notes do not address authorization granularity on documents, cross-tenant leakage via filters/relation managers, or audit expectations — those are contract-system table stakes.
• We are on Filament v4 and cannot upgrade. Adopting means an unsupported island; that is a schedule risk disguised as a dependency.
• We need DOCX round-tripping or Word-fidelity editing. This is HTML-and-print oriented; the PDF driver is undocumented in the release notes, so font support, page-break fidelity, repeated headers/footers, and render cost are all unvalidated assumptions.
• We need high-volume batch generation, an SLA, vendor support, or a peer group of production users to lean on for edge cases. There are effectively zero dependents.
• We have existing Tiptap-authored templates. v5 moved storage to Filament's RichEditor; template HTML is not guaranteed to survive, and re-authoring should be assumed, not hoped against.
• Our templates depend on inline styles, custom classes, embedded fonts, iframes, or data attributes. HTML is now sanitized on save and render — this is a behavior change, not just a fix, and branded output will silently degrade without an explicit allowlist audit.

Two gating questions before any commitment: (1) Are we on Filament v5, and if not, is the upgrade in scope? (2) Do we accept that the HTML sanitizer policy must be audited against our real templates before anyone signs off on print fidelity?

How to Pitch It (Stakeholders)

For executives — one paragraph. We can put template-driven document and contract generation into our admin panel for roughly one to two days of evaluation and a small integration effort, instead of building an editor, a variable system, and a print pipeline ourselves. It's MIT-licensed, so there's no procurement, no per-seat cost, and no lock-in — the code is ours to keep, fork, or replace. It deliberately covers generation and printing, not signing and governance, which is the right v1: it gets the workflow live and defers the expensive, high-commitment parts (e-signature, approvals, audit trail) until we have usage evidence. The main caveats are honest ones: it depends on our Filament version, the maintainer is a single small team, and anything legally binding still requires work we'd own.

For engineering — the summary. Filament-native, not a parallel stack: two models, one plugin, a facade-backed variable registry, and a print/PDF render path — so the architectural delta is small if we're already on Filament. v5.0.0 removed Tiptap in favor of Filament's built-in RichEditor, collapsing to one editor stack and one asset pipeline, and it replaced a Tailwind CDN reference with a bundled print stylesheet (good for regulated and air-gapped environments, but it means we inherit their print CSS and need an override strategy that survives upgrades). It ships a test suite covering resources, print page, actions, relation manager, and the install command, plus model factories — which lowers our own test-authoring cost. Security posture improved (HTML sanitized on save and render; title/URL escaped in print-action JavaScript) but is not complete. Known gaps we inherit: Filament v4 is unsupported, tenancy is a hand-written migration we own, and the PDF driver is unspecified — validate page breaks, headers/footers, fonts, and image handling against a real contract before we estimate further. Mitigation is straightforward: keep the integration behind a thin internal boundary so we can vendor or fork rather than be stranded by a broken major version.