Technical Evaluation

Architecture fit

Invoicematic is a Statamic addon, not a standalone Laravel package. It only fits stacks running Statamic (Pro) on Laravel; it is not usable in a plain Laravel app or a headless non-Statamic CMS. Confirm the Statamic major version on our installs before anything else.
The design is content-lifecycle-coupled: it hooks entry save/create events, renders a Blade view to PDF, writes the file to a Laravel filesystem disk, and stores the resulting path back on the entry. That is a clean, idiomatic fit for "entry = document" domains (orders, quotes, receipts, statements, booking confirmations).
It is a document generator, not an invoicing system. There is no mention of sequential numbering, immutability/versioning of issued documents, tax/currency handling, credit notes, or audit trails. If Finance intends to use this for statutory invoices, that is a gap we own, not the package.
The "PDF path stored in entry" pattern makes the entry the source of truth for a file that lives outside the database. That coupling is simple but fragile across environments (local vs S3 vs multi-site) and across content sync/import.

Integration feasibility

Installation is low-effort: composer require, publish config, define a Blade template, map fields per collection. A Laravel-fluent developer can produce a working PDF in a day.
The real effort is in the non-code work: template design, field mapping correctness, storage disk and retention decisions, and access control on the generated files.
Email delivery is the main architectural decision point. Release notes do not state whether sending is queued. Synchronous send on entry save will block the Control Panel and couple user experience to SMTP/provider latency and attachment size limits.

Technical risk

Maturity: v1.0.0, no prior assessment, no signal on test coverage, CI, or maintainer depth. Treat as bus-factor-1 until proven otherwise.
Regulated domain: if outputs are financial documents, a template edit can silently change what a re-generated document looks like. Without immutable snapshots, we cannot defend historical documents. This is the largest risk and it is ours to mitigate.
PII / GDPR: PDFs contain personal and financial data. Unspecified is how generated files are protected — public disk vs private disk, signed URLs, retention/deletion. Email delivery widens the blast radius.
Silent failure: field mapping is per-collection configuration. A renamed field or an empty relation can produce a valid-looking PDF with blanks rather than an error.
Unknown PDF engine: dependency on dompdf/Snappy/wkhtmltopdf/Browsershot determines memory, binary dependencies, and font/CJK support. Unanswered by the notes.

Key questions

Which Statamic and Laravel/PHP versions are supported, and what is the upgrade story across Statamic majors?
Which PDF engine, and does it need system binaries (headless Chrome, wkhtmltopdf) we would have to provision in CI and production?
Is generation triggered on save, and is email delivery queueable/queued by default? Is there a manual "regenerate" action?
Are generated PDFs written to a private disk by default, and how are they authorized on download?
Is there any document versioning, numbering, or immutability support, or is regeneration always destructive?
Multi-site / multi-locale behaviour — does each site get its own template, disk, and numbering?
Test coverage, CI status, license, and maintainer/backing (individual vs agency)?

Integration Approach

Stack fit

Greenfield-friendly and additive: no schema changes beyond a field on the target collection. It sits alongside existing Laravel mail, queue, and filesystem configuration rather than replacing anything.
Best fit: a Statamic site already modelling business objects as entries, with a queue worker and a private storage disk in place. Worst fit: a plain Laravel API, or a site where documents are legally binding and must never be re-rendered.

Migration path

There is no migration from an incumbent PDF pipeline — the addon generates, it does not import. Any existing manual or custom PDF flow runs in parallel.
Recommended path: pilot on a single low-stakes collection (e.g. quotes or confirmations), compare output against the current manual document for one full cycle, then promote to higher-stakes collections.
Reserve the option to fall back to the existing process; keep the pilot behind a feature flag or a single collection so rollback is a config change, not a revert.

Compatibility

Verify: Statamic major, PHP version, PDF engine binaries in our container image, storage driver behaviour (S3 needs signed/temporary URLs, not raw paths), and mail provider attachment size ceilings (typically 10–25 MB).
Blade templates imply our front-end/design conventions apply; confirm whether the addon ships views we would need to override and whether overrides survive package upgrades (publishable views vs vendor paths).

Sequencing

Staging spike on a scratch collection — prove render, storage, and email end to end.
Template and field-mapping design with design + (if financial) finance/legal review before any production wiring.
Storage and retention decision: private disk, naming convention, lifecycle/deletion policy.
Move email delivery to the queue; add failure alerting.
Access control on generated files (authorization policy or signed URLs).
Production pilot on one collection, observed for one full business cycle.
Expand collection by collection; only then consider statutory use, with an immutable-snapshot plan in place.

Maintenance

Pin the exact version. A v1.0.0 package in a regulated output path should not float. Budget a review on every Statamic major upgrade — addons are the usual breakage point.
Template and field-mapping changes become production changes with document-level consequences; they need review and a change log, not a Control Panel edit-and-save.

Support

Support model is unstated. Assume community/individual maintainer. Because a failure here produces either no document or a wrong document, we should be prepared to fork or vendor the package, and should keep the custom Blade templates in our own repo so the fork surface stays small.

Scaling

PDF rendering is CPU- and memory-bound. Synchronous rendering on entry save degrades Control Panel responsiveness under bulk imports or content migrations; anything at volume must go through a queue with a dedicated worker pool.
Storage grows monotonically and is not self-cleaning. Without a retention policy, PDFs accumulate indefinitely on the disk and in backups — cost plus a GDPR exposure.

Failure modes

Render error on save blocking the editorial workflow (if synchronous and unhandled).
Email send fails after the PDF is stored → partial state with a path recorded but no delivery; needs retry and reconciliation.
Stale or orphaned paths after disk migration, environment sync, or content import.
Blank-field PDFs from renamed/removed fields, produced silently and mailed to customers.
Disk full or S3 permission drift, surfacing as intermittent failures under load.
Retroactive template edits changing historical documents on regeneration.
Multi-site cross-contamination: wrong template or wrong disk for the wrong site.

Ramp-up

Technical ramp-up is low: one Laravel developer, roughly one day to a working pilot, roughly one week including storage, queueing, and access control.
Organisational ramp-up is the real cost: finance/legal sign-off, a numbering and retention decision, and a documented "these documents are not statutory invoices" boundary until the immutability gap is closed. Plan for that in weeks of calendar time, not days of engineering.