Framework Laravel Package

Product Decisions This Supports

• Build vs. buy for internal operations tooling. A PHP/ERP package in the same runtime as an existing Laravel stack is the cheapest path to CRM, order, invoice, or inventory back-office features without standing up a separate SaaS vendor, a second identity model, or a second deployment pipeline. The decision it informs: do we extend our app, license a SaaS ERP, or adopt this?
• Roadmap sequencing for admin/back-office scope. If the package already covers customers, products, and documents, the roadmap can absorb "internal ops" epics that would otherwise compete with customer-facing work for the same sprint capacity.
• Data ownership and exit-cost planning. Self-hosted ERP data means the schema lives in your database. That is a real strategic lever when negotiating with vendors or planning a migration — worth capturing as an explicit architectural bet in the roadmap.
• Deprioritizing greenfield work. The strongest PM outcome here is a negative one: confirming a capability is already covered, and reallocating that engineering budget to differentiators.
• Timing and risk posture. This is 2.0.0-alpha3. The release itself supports a decision about when to adopt — not whether the domain is relevant. Alpha means the roadmap should slot any dependency on it behind a stabilization gate.

Caveat worth flagging to yourself: the release notes for this version read only "See hubleto/erp repository for more details." That is not a changelog. It tells you the project publishes notes in the monorepo rather than per-package, which means any adoption decision requires reading the upstream repository, not the package release feed. Treat the package feed as a version signal only — never as an upgrade-safety signal.

When to Consider This Package

Adopt when:

• Your stack is already PHP/Laravel and you want back-office capability without adding a service, a vendor contract, or a second set of user accounts.
• The required scope is conventional ERP/CRM ground — customers, contacts, products, orders, invoices, documents — and your differentiation does not live there.
• You are comfortable owning the database, backups, upgrades, and the operational burden that self-hosting implies.
• You can absorb volatility. At alpha, expect breaking changes between releases and plan to pin versions and read upstream notes before every bump.

Look elsewhere when:

• You need a support contract, SLA, compliance attestation, or vendor accountability. A package alpha with a cross-referenced changelog does not provide those.
• Finance, payroll, or tax reporting is in scope — regulated domains demand a vendor with liability and audit history.
• Your team is not PHP-native; the integration savings evaporate if nobody can debug it.
• The roadmap requires the ERP surface to be stable for a year or more. Alpha-stage dependencies should not sit under committed external dates.
• You need a per-release changelog as a governance input. This project does not publish one at the package level, which makes routine upgrade review more expensive than usual.

The practical gate: run a time-boxed spike against your real schema and one real workflow before any roadmap commitment. Version numbers are not evidence of fitness.

How to Pitch It (Stakeholders)

To executives: This is a self-hosted PHP package covering standard back-office functionality — customers, products, orders, documents. It is the low-cost option for internal tooling we would otherwise buy as a subscription or build from scratch. Two things to be clear about: it is currently pre-release (alpha), and there is no commercial support behind it. So the recommendation is not "adopt" — it is "evaluate with a bounded spike," and only commit once it stabilizes. If the spike succeeds, we avoid a recurring vendor cost and keep the data in our own database; if it fails, we have spent a few engineer-days learning that.

To engineering: Same runtime as our existing Laravel app — no new service, no new auth model, data in our own database. It is alpha, so pin the version, and note that release notes live in the upstream hubleto/erp repository rather than in this package's changelog; upgrades require reading the monorepo, not the package feed. Scope the spike to one workflow end-to-end so we learn the extension model and the upgrade path at the same time.

The honest framing: the value proposition is cost and integration simplicity. The risk is maturity and maintainer dependency. Both are true, and the spike is how we price the risk before the roadmap depends on it.