Tomato Invoices Laravel Package

Product Decisions This Supports

• Build vs. buy for invoicing/billing surfaces: tomatophp/tomato-invoices is a Laravel-native invoice package (TomatoPHP ecosystem, typically paired with Filament admin panels). It can replace a from-scratch invoice CRUD module for internal tools, back-office admin, or early-stage SaaS billing—reducing weeks of build time to days of integration.
• Roadmap sequencing: Because it is a v1.x package with patch-level releases, treat it as an accelerator for non-differentiating back-office functionality (invoice records, line items, product linkage, PDF/print flows) rather than as the foundation of a differentiated billing engine. Keep pricing, tax, proration, and payment-provider logic in your own domain layer.
• Feature triage: The v1.0.5 fix addresses the products route—a routing defect in the product-to-invoice linkage. This tells you the product catalog → invoice line-item flow is actively used and being corrected, which is a reasonable signal that the core CRUD path is receiving attention. It should not, on its own, drive any roadmap change.
• Use cases where it fits well: internal finance/admin dashboards, agency or SMB invoicing, ERP-style back-office modules, MVPs where invoices must exist before billing is productized.
• Use cases to route elsewhere: usage-based/metered billing, multi-currency tax compliance, dunning and subscription lifecycle management, or anything requiring auditable, regulator-facing invoice numbering guarantees.

When to Consider This Package

Consider adoption when:

• Your stack is Laravel (and especially Filament) and you want invoice CRUD that matches the ecosystem's conventions rather than a bespoke module.
• Invoicing is a supporting capability, not your product's core value—i.e., you can tolerate upstream churn and patch-level fixes.
• You need speed to first demo: products, invoices, and line items wired up without designing schema and admin UI from zero.
• You can vendor/fork the package or pin a version, and you have engineering capacity to review the route and controller layer before shipping.

Look elsewhere when:

• You need regulatory-grade invoicing (sequential numbering, immutability, audit trails, e-invoicing formats). This release is a routing fix—not evidence of compliance hardening.
• You require payment gateway integration, subscriptions, or tax engines as first-class features; expect to build or integrate these yourself.
• Bus factor and longevity matter. v1.0.5 is a single-commit patch with a first-time contributor. A one-person-maintainer package at patch-level maturity carries maintenance risk; confirm release cadence, test coverage, and issue responsiveness before committing.
• You need semantic versioning guarantees. Route fixes shipping as patches is normal, but validate that the public API surface (routes, models, migrations) is stable and documented.

Due diligence checklist before committing: review the CHANGELOG across v1.0.0→v1.0.5, inspect migration and model definitions for schema lock-in, confirm test presence, and check whether the products route fix implies consumers were silently broken (i.e., assess how regressions are caught).

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost Laravel package that gives us invoice and product-catalog screens out of the box. The latest release (v1.0.5) is a one-line bug fix to a products route—no new features, no breaking changes, no action required. Recommendation: do not adopt as a strategic dependency. Evaluate it as a time-saver for internal admin tooling only, and budget engineering review time before any customer-facing use.

For engineering: v1.0.5 is a maintenance patch from a first-time contributor fixing the products route; API surface unchanged. Before we depend on it, we need to (1) pin the version, (2) review the routing and controller layer for the products/invoices boundary, (3) confirm migration stability, and (4) decide whether we vendor it. If we need tax, payments, or subscription logic, we build that ourselves behind our own interfaces so this package stays swappable.

Bottom line: Low-risk to trial, moderate-risk to depend on. The patch itself is a non-event; the signal is a young, single-maintainer package—so isolate it behind an abstraction and keep an exit path.