Tomato Tasks Laravel Package

Product Decisions This Supports

• Build vs. buy for internal task tracking. tomato-tasks (TomatoPHP) is a task-management module for Laravel/Filament admin panels. The decision it informs: ship an in-product task/issue tracker, or pay for Jira/Linear/Asana/ClickUp seats. For internal-only workflows, this package can collapse weeks of scaffolding into days.
• Roadmap sequencing. It supports adding a "tasks" or "activity backlog" surface to an existing admin panel without opening a platform migration. Useful for MVP scoping, ops tooling, and replacing ad-hoc spreadsheets.
• Admin-console consolidation. If you are already running Filament (a TomatoPHP ecosystem convention), this is a thin add-on rather than a separate product with its own auth, hosting, and vendor contract.
• Maintenance-health signal (this release). v1.0.2 fixes "Undefined Array Key 0" and property-access errors — the kind of rough edges that surface when a v1.0 shipped slightly ahead of real-world data shapes. The fix landed via a first-time external contributor (PR #4 from @abdelmjid-saber), which is a modest but real positive signal: the project accepts outside patches and is actively stabilising. It does not yet indicate the depth of maintenance (versioning policy, test coverage, security response) you'd want for a customer-facing commitment.

When to Consider This Package

Consider it when:

• You are on Laravel + Filament and want native, in-panel task management rather than an embedded third-party iframe.
• The use case is internal: team backlog, ops checklist, support follow-ups, simple assignment/status tracking.
• You want no per-seat SaaS cost and are willing to own the code.
• You are comfortable treating a v1.x, pre-1.1 package as a starting point you may fork or extend.
• You value a small dependency surface over feature breadth.

Look elsewhere when:

• You need customer-facing ticketing — SLAs, external requester portals, email ingestion, audit trails.
• You need deep workflow automation: custom state machines, approval chains, cross-project dependencies, reporting/BI.
• You require hard permission models (per-project roles, field-level ACLs) or compliance controls (SOC 2, data residency).
• You need first-class integrations with GitHub, Slack, Jira, or CI. Expect to build these yourself.
• You are not on Filament, or on a stack where a bespoke Livewire module would be simpler than adopting a package.
• Your team cannot absorb ownership risk: single-maintainer-adjacent ecosystem, thin evidence of test coverage, no published security policy visible from the release metadata.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-commitment way to give the team an internal task tracker inside tooling we already run, avoiding per-seat SaaS spend. It is not a Jira replacement — it's a stopgap or a module for operational workflows we control. Risk is contained: the package is small, the code is ours to inspect and fork, and the latest patch shows it is still being maintained.

To engineering: Small Laravel/Filament package; adopt behind an interface so we can swap or fork later. Budget roughly a day to spike it against our real data shapes — the v1.0.2 fix (undefined array key and property access errors) tells us v1.0 shipped with some data-shape assumptions that early adopters hit. Pin the version, add smoke tests around the task list and edit flows, and treat upstream as a convenience rather than a dependency we can't replace. Verify the Filament/Laravel version matrix before committing.

Recommendation: Proceed to a time-boxed spike, not a production commitment. Decision gate: if the spike shows the data model fits and the package passes basic CRUD and permission smoke tests, adopt for internal use; otherwise fork or build a thin bespoke module.