Tomato Crm Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for CRM-adjacent scope. Use this package as a concrete strawman for the minimum viable CRM — accounts, contacts, leads, companies, deal stages, activity history, API, notifications — before committing engineering cycles. Even when the answer is "build in-house," evaluating against a real data model, real migrations, and a real API surface makes the scope conversation faster and cheaper than whiteboarding from scratch.
• Roadmap sequencing when CRM is a prerequisite, not the product. Customer records, contact management, and notification flows gate a surprising amount of adjacent work: customer portals, onboarding checklists, billing contacts, support tooling. Where those are blocked on CRM plumbing, this package is a schedule lever that can compress a multi-month build into weeks and free the roadmap for differentiating work. It is a schedule lever, not a strategy lever.
• Internal tooling and back-office ops decisions. A credible, near-zero-license-cost path to giving ops or support a working account manager when customer-facing polish and uptime SLAs are not requirements.
• Pricing and packaging scoping. If CRM becomes an add-on tier or paid module, this gives a baseline feature set to price against and a realistic read on marginal delivery cost — MIT licensing means the cost is engineering ownership time, not license fees.
• Forcing the architecture and data-model conversations the team should have anyway. The accounts → contacts → notifications structure and its ownership patterns clarify internal questions — how notifications attach to records, how entities relate, how the API is shaped — whether or not the package is ultimately adopted.
• What this should not drive: platform architecture commitments, enterprise or compliance positioning, anything requiring a vendor relationship, SLA, or security review artifact, and any roadmap where CRM is itself the differentiator.

When to Consider This Package

Consider it when:

• Your stack is Laravel, and ideally already Filament/TomatoPHP-aligned. Architectural fit here is close to binary — outside that ecosystem you would be adopting an entire opinionated admin framework to get a fairly small domain model.
• CRM is a supporting capability, not the product's core bet.
• You are time-boxed (MVP, pilot, internal launch) and can accept a fork-and-own maintenance model.
• Your needs are the fundamentals — accounts, contacts, notifications, a basic API — not forecasting, deep pipeline analytics, or workflow customization.
• You have a named engineer willing to own a vendored fork, pin versions, and test the API and notification contracts you expose.
• The maturity signal is tolerable: ~3 stars, 0 dependents, single maintainer, last release May 2024. Viability rests on your ownership, not on upstream.

Look elsewhere when:

• You need SLAs, security review artifacts, or a maintained release cadence. There is no evident commercial backing and effectively no public knowledge base.
• CRM is the product. Differentiation and forecasting will quickly exceed a thin accounts/contacts layer.
• You need multi-tenancy, granular permissions, audit trails, or validated data-residency guarantees — none are confirmed by the docs, so assume single-tenant and no audit table until the migrations prove otherwise.
• You are on a brownfield schema. CRM migrations can collide with existing users, accounts, or notification tables, and there is no upstream guidance for reconciliation.
• Procurement or infosec will block low-maturity dependencies. Vet this before sprint planning, not during it.
• Your team will not sustain a fork indefinitely — an unmaintained dependency you do not own is a future outage.

Mitigation if adopted: fork or vendor internally, pin tomatophp/* and Filament versions with a committed lockfile, write tests around anything customer-facing, and assign an owner with a quarterly maintenance allowance. Also weigh a one- to two-week in-house build of an equivalent accounts/contacts module — for a domain this small, that is often the cheaper strategic answer.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel component that provides a ready-made accounts and contacts manager with an API and notifications, built for the Filament/TomatoPHP admin stack. It lets us stand up CRM-adjacent functionality — customer records, contact management, alerting — in a fraction of the time of a custom build, at effectively zero license cost. The trade-off is maturity: minimal adoption, a single maintainer, and a release line last updated in May 2024, so we should treat it as a starting point we own and fork, not a supported vendor product. Recommendation: adopt for non-differentiating, internal-facing or MVP scope where the stack already aligns; do not anchor core platform strategy on it. Expected cost is engineering ownership time, not licensing — and the credible alternative, a narrow in-house build, is roughly one to two weeks.

For engineering: It is a TomatoPHP/Filament module, not a standalone CRM library — plan to vendor it into the repo and assume we own the maintenance. First tasks: audit the published migrations and the accounts/contacts schema, review the API surface (auth model, pagination, rate limiting) by reading routes rather than docs, inspect the transitive tomatophp/* dependency tree, and pin exact versions with a committed lockfile. Spike it in a disposable repo first and treat dependency conflicts as a go/no-go signal, not something to patch around. Wrap the models in a thin service layer so call sites survive a fork or replacement, queue the notification path, eager-load relationships on contact listings to avoid N+1s, and write feature tests against the endpoints we expose. Flag the stale release date and near-zero dependents as maintenance risk, and assign an owner before adoption so the fork does not quietly go stale.