Goodwork Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. If your roadmap includes time tracking, invoicing, or client/project management as a means to an end (not your differentiator), Goodwork is a credible "borrow" option: MIT-licensed, self-hosted, and covering the full loop of client → project → time entry → invoice.
• Foundation for a niche SaaS or white-label product. The Laravel + Filament stack makes it realistic to fork, rebrand, and ship a verticalized offering (e.g., agency ops, freelance billing, consultancy back-office) in weeks rather than quarters. This is a "buy the 70%, build the 30%" decision.
• De-risking a framework bet. Evaluating Filament for your own admin surfaces? This is a working, non-trivial reference implementation of Filament resources, policies, and CRUD at scale — useful evidence before committing your team to the stack.
• Roadmap sequencing. Adopting or forking removes an estimated one to two quarters of undifferentiated CRUD, auth, permissions, and reporting work from the early roadmap, letting the team spend that capacity on the actual differentiator.
• Delivery model decision. Self-hosted vs. cloud is a product-strategy question; this package is a concrete artifact for the "self-hosted / data-residency" option, including for customers who cannot send financial or client data to a third party.
• Reference architecture for in-house Laravel teams. Even if you don't adopt it wholesale, it informs schema, invoicing, and permission-model decisions.

When to Consider This Package

Consider it when:

• Your team is already proficient in PHP/Laravel; the marginal learning cost is near zero.
• You need the combination of time tracking, invoicing, and project/client management — not just one of them.
• Data sovereignty, on-prem deployment, or per-customer isolation is a requirement or a selling point.
• You are budget-constrained and can absorb maintenance in engineering time instead of license fees.
• You want a forkable base you can differentiate on, and you accept owning that fork.
• You need a credible prototype or internal tool live within a sprint or two to validate demand.

Look elsewhere when:

• You need enterprise-scale multi-tenancy, SSO/SCIM, granular RBAC, audit trails, and a support SLA. Evaluate commercial options (Harvest, Toggl, FreshBooks) or a heavier open-source suite before forking.
• Your engineering organization is not PHP-based. The fork becomes a permanent skills tax.
• Country-specific e-invoicing, tax compliance, or accounting-system integration is core — verify coverage explicitly rather than assuming; this is often the real cost center.
• You need native mobile apps, a broad integration marketplace, or high-volume performance guarantees.
• You require a stable public API contract with semantic versioning. Important framing: this is an application, not a library. You do not composer require it into an existing product; adoption means forking and maintaining a downstream. Assess it as starter code, not as a dependency.
• A single-maintainer or small-maintainer project is an unacceptable supply-chain risk for a revenue-critical system.

How to Pitch It (Stakeholders)

For executives: Goodwork is a mature, MIT-licensed, self-hosted business application covering time tracking, invoicing, and client/project management — roughly the back-office layer most services businesses rebuild from scratch. The license cost is zero; the real investment is engineering ownership of a fork. Recommended path: a two-to-three week technical spike to quantify how much of our target scope it covers, then a go/no-go on fork-versus-build. Expected outcome is a materially shorter path to first revenue, with the trade-off being long-term maintenance responsibility and reduced vendor accountability.

For engineering: Standard Laravel and Filament — no exotic dependencies, no unfamiliar paradigms. The adoption model is fork-and-rebase, not versioned dependency upgrades, so we should plan an explicit upstream-sync cadence and treat the initial fork point as a versioned baseline. Key diligence items: test coverage, migration stability, permission model extensibility, and how cleanly invoicing/tax logic can be localized.

For product: Treat this as an accelerator for commodity capability, not a strategy. It buys back calendar time on non-differentiating features; it does not resolve positioning, pricing, or workflow differentiation. The decision to adopt should be contingent on the spike demonstrating that our differentiated requirements live in the extensible 30%, not in the parts we would be fighting.