Tomato Freelancers Laravel Package

Product Decisions This Supports

• Feature scoping for freelancer/marketplace workflows — tomato-freelancers is a Laravel module in the TomatoPHP ecosystem, which positions it as a starting point for freelancer, client, and project-management surfaces (profiles, engagements, deliverables) rather than a generic CRUD add-on. Useful as a reference architecture when scoping an MVP.
• Build vs. buy for admin/back-office tooling — For teams already on TomatoPHP, this is a candidate to buy (adopt) instead of building freelancer management primitives in-house, freeing engineering capacity for differentiated product work.
• Roadmap acceleration for prototyping — At v0.0.1, the realistic product use is prototype and internal demo, not customer-facing roadmap commitments. It can de-risk a discovery phase or a stakeholder demo at low integration cost.
• Ecosystem bet assessment — Adopting this is implicitly a bet on the TomatoPHP maintainer and module ecosystem. Treat it as a portfolio decision: a low-cost experiment, not a platform commitment.
• Use cases to evaluate against: freelance marketplace MVPs, agency resource/engagement tracking, services CRM dashboards, internal ops portals.

Caveat for decision-making: v0.0.1 ships with a changelog link only — no documented feature list, stability guarantees, or migration notes. Any decision should be contingent on a hands-on spike, not on the release note.

When to Consider This Package

Consider it when:

• You are already running Laravel + TomatoPHP; the integration cost is low and the module composes with existing admin scaffolding.
• You need speed over longevity — a discovery prototype, an internal tool, or a proof-of-concept to validate a freelancer/marketplace concept.
• You have engineering capacity to read the source and own the risk, since documentation and API stability are unproven at 0.0.x.
• You want a reference implementation to inform your own build, even if you don't ship the package itself.

Look elsewhere when:

• You need production SLA, LTS, or semantic-versioning guarantees — 0.0.1 is pre-stable by definition; APIs can break in any patch.
• You are not on TomatoPHP — adopting a whole ecosystem for one module is rarely justified.
• You require vendor support, security review artifacts, or compliance documentation; none are evidenced here.
• Your domain needs are deep (payments, escrow, contracts, compliance) — this package will not cover regulated marketplace mechanics.
• You are non-Laravel/PHP.

Pre-adoption checklist for engineering: pin the exact commit, vendor/fork it, confirm test coverage and maintenance cadence (commit history, open issues, last release date), and define an exit plan to replace it if the ecosystem stalls.

How to Pitch It (Stakeholders)

For executives: A small, free, open-source Laravel module for freelancer-style workflows has appeared in the TomatoPHP ecosystem. Cost of trial is measured in engineering hours, not licence fees. The strategic value is option value: it lets us prototype a freelancer/marketplace surface quickly and cheaply, and it gives us a concrete artifact to benchmark our build-vs-buy thinking against. The risk is maturity — this is a 0.0.1 release with no published feature documentation and no stability guarantees. Recommendation: fund a time-boxed spike (1–2 engineering days) inside a non-customer-facing environment; do not commit it to a production roadmap until the spike and a maintenance-health review pass.

For engineering: Treat as an unvetted dependency with a permissive-but-unknown licence posture and an unstable public API. Spike scope: install in a sandbox Laravel app, map the actual data model and endpoints against our requirements, audit test coverage and dependency weight, check maintainer activity and issue responsiveness, and record findings in an ADR. Pin to a commit SHA if we proceed; assume we may need to fork. Report back with a go/no-go against our own build estimate, not against the package's marketing.