Tomato Hr Laravel Package

Product Decisions This Supports

• Build vs. buy for internal HR surface area. tomato-hr sits in the TomatoPHP ecosystem (Laravel + Filament admin panels), so the real decision it informs is whether to buy a full HRIS (BambooHR, Gusto, HiBob) or self-host a thin employee-records layer inside an existing Laravel admin. This package is a candidate for the thin side of that split — employee profiles, org structure, and admin CRUD — not the compliance side.
• Scope boundaries for an "HR module" in our own product. If we're adding people-management features to a Laravel app, this is a reference implementation to benchmark our own data model against (employees, departments, job titles, reporting lines, documents). Useful for estimating effort before we commit engineering weeks.
• Roadmap sequencing for internal tooling. Because it's a v1.0.0 initial release, it establishes a starting point rather than a mature dependency. That frames the roadmap question as "is a 20–40% head start worth the maintenance tail?" rather than "which vendor do we sign with?"
• Feature gap identification. Any capability not present at v1.0.0 — leave/PTO accrual, attendance/time tracking, payroll export, document expiry alerts, approval workflows — becomes either our differentiation or our integration workstream. This is the fastest output from an evaluation.
• Ecosystem leverage decision. Adopting TomatoPHP components compounds: shared auth, permissions, Filament resources, and UI conventions. The decision is partly "do we standardize on this ecosystem?" — which is a platform bet, not a single-package bet.
• Use cases it plausibly serves. Internal admin for a 20–200 person company on Laravel; an HR back-office embedded in a larger custom ERP; a starting scaffold for an agency building a client-specific HR tool. It does not obviously serve payroll, benefits, or multi-country compliance.

When to Consider This Package

Consider it when:

• You are already on Laravel and Filament, and ideally already using TomatoPHP packages — the marginal integration cost is then low and the consistency benefit is real.
• Your requirement is employee records and org structure, not payroll, tax filing, or statutory compliance.
• You need an admin-facing internal tool for a small-to-mid headcount where a per-seat SaaS contract is hard to justify.
• You want a scaffold to fork rather than a vendor to depend on — i.e., you're comfortable owning the code.
• You can absorb the risk of a v1.0.0 with a changelog that contains no substantive release notes (only a diff link). Someone must read the code and the migrations before it touches production data.

Look elsewhere when:

• Payroll, benefits, or compliance are in scope. This is not a substitute for a payroll provider in any jurisdiction, and mis-scoping here is an expensive, hard-to-reverse error.
• You need guaranteed support SLAs, security attestations (SOC 2), or a vendor liable for data-handling obligations. A community package shifts that liability to you.
• You are not on Filament/TomatoPHP. Porting cost likely exceeds building the narrow slice you actually need.
• You require multi-tenant isolation, field-level audit trails, or GDPR-grade data subject tooling out of the box — assume these must be built and budget accordingly.
• The team has no appetite for tracking an early-stage dependency's API churn across future minor versions.

Required due diligence before adoption: pin the version, read the migrations and models, confirm test coverage, check license terms and the maintainer's release cadence, and verify how employee PII is stored and who can read it. The absence of release notes is itself a signal about documentation maturity — treat it as a cost line, not a red flag that ends the conversation.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated tomato-hr, an open-source HR admin module for Laravel from the TomatoPHP ecosystem, at its first stable release. It gives us employee records and org structure inside our existing admin panel at near-zero licensing cost, which is attractive for an internal tool at our headcount. It is explicitly not a payroll or compliance system — those stay with a specialist vendor. My recommendation is a time-boxed spike, not a commitment: one engineer, roughly one week, to stand it up in a sandbox and report on code quality, data model fit, and the true cost of the gaps. That spend is small against the alternative of several engineering weeks to build the same CRUD layer, and it produces a reusable estimate either way.

To engineering (the ask): v1.0.0 shipped with no meaningful release notes, so the evaluation is the code review. Specifically: read the migrations and models for the employee/department schema; check test coverage and CI; identify how PII is stored, logged, and authorized; list which Filament resources are provided versus stubbed; and confirm upgrade risk by reviewing the maintainer's release history. Report back with a build-vs-fork-vs-buy recommendation and a maintenance estimate — who owns this when the upstream goes quiet. Pin the version in the sandbox; do not merge to main during evaluation.

Positioning line: low-cost head start on the boring 60% of HR admin, with an explicit, pre-agreed boundary at payroll and compliance.