Invoicematic Laravel Package

Product Decisions This Supports

• Build vs. buy for document generation: Invoicematic collapses a common "we need PDFs of our content" backlog item (invoices, receipts, certificates, order confirmations, statements) into configuration rather than custom code. A PM can use this to justify deferring a bespoke PDF service and reallocating that engineering time.
• Roadmap sequencing for billing/fulfillment features: If your roadmap includes "send customers a PDF on purchase," "issue renewal invoices," or "generate compliance documents," this package defines the minimum viable path — content in a Statamic entry, a mapped template, a stored file, an optional email — so you can scope those epics realistically.
• Self-serve vs. manual operations: Automating generation and delivery removes a manual ops step (someone exporting and emailing PDFs). This is a concrete operations-cost argument for headcount planning or for reducing per-order handling time.
• Content-model decisions: Per-collection field mapping means the PDF is driven by your existing entry schema. That is a forcing function to decide which fields are canonical for financial/customer documents and to standardize collections before launch — a data-model decision worth making deliberately rather than retrofitting.
• Template ownership and brand control: Blade templates plus config keep document layout in-repo and reviewable, so design/brand changes are a config-and-template task rather than a vendor ticket. Supports decisions about who owns customer-facing document design.
• Buy-in on scope boundaries: The package stores a path on the entry and optionally emails it; it is not a full billing system, ledger, tax engine, or payment processor. That boundary is useful for cutting scope explicitly in planning.

When to Consider This Package

Adopt when most of the following hold:

• Your content and customer records already live in Statamic entries — this is a Statamic addon, not a generic Laravel package, and its value depends on that assumption.
• The documents are template-driven and repetitive (invoices, receipts, confirmations, certificates) with data already present on the entry.
• Email delivery is sufficient as a distribution channel, or you can live with the generated file stored on the entry and handle delivery elsewhere.
• You want versioned, code-reviewed templates (Blade) rather than a hosted document builder or a no-code tool.
• You are comfortable with a v1.0.0 package — first public release, small surface area, no long track record. Expect to read the source and pin the version.

Look elsewhere when:

• You need a real billing/invoicing system: tax calculation, VAT/GST rules, sequential legal numbering, credit notes, dunning, multi-currency ledgers, audit trails, or e-invoicing compliance. Those belong in a dedicated provider (Stripe Invoicing, a billing platform, or an accounting integration).
• You are not on Statamic, or your document data lives in an external system of record.
• You need high-volume, queue-heavy batch generation with retries, idempotency, and observability as first-class features — validate this before committing; v1.0.0 gives no evidence either way.
• Documents must be legally authoritative and immutable with retention guarantees; storing a path on an entry is convenient but not an archive strategy.
• You need localization of layouts at scale or a non-developer editing flow for templates — Blade templates keep this in engineering's hands.

How to Pitch It (Stakeholders)

For executives: A small, focused addon that turns content we already manage into finished PDF documents and emails them automatically. The business case is time and risk: it removes a manual export-and-send step, and it avoids paying for either a bespoke build or a per-document SaaS subscription. Cost is low, scope is deliberately narrow, and the main caveat is maturity — this is a first release, so we should pilot it on a low-risk document type before it touches anything customer-critical.

For engineering: It is a Statamic addon that generates PDFs from entries using custom Blade templates, with per-collection field mapping, the resulting file path persisted on the entry, and optional email delivery with the PDF attached. Adoption cost is small — config plus a template per collection. Key diligence items before we commit: PDF rendering engine and its memory/time characteristics, whether generation is queued or inline (blocking a web request during checkout would be unacceptable), idempotency if an entry is saved repeatedly, behavior on template failure, where files are stored and how they are backed up, and whether regeneration overwrites or versions. Pin the version and read the source; at v1.0.0 there is no stability guarantee and no migration history.

Recommended next step: timebox a spike — one collection, one template, one document type — and confirm queueing, storage, and regeneration behavior before promoting it to billing-critical or customer-facing use.