Ecommerce Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for a commerce backend — still the "build" branch, but with sharper edges. v1.0.3 confirms this is a real application, not a bare skeleton: Filament admin and /app panels covering Products, Orders, Invoices, Customers, plus articles/collections, a team/tenant model, a storefront with /orders, /wishlist, /invoices, /payment_methods, and social login. That is a meaningful head start on the plumbing and admin surface of commerce. It still evidences nothing for pricing, tax, shipping, promotions, inventory correctness, or payments — and the release notes show the domain layer is where the debt lives.
• A worked example of authorization design — and of how it fails. The release documents an auth bypass class bug: every registrant was attached to Team::first() (the merchant's own team) with a staff role, while canAccessPanel ended in return true; // TODO. It only stayed hidden because registration threw first. This is directly usable as a design review artifact for our own multi-tenant authz model, and as a concrete argument for buying an authz-reviewed platform if we cannot staff a security review.
• Security posture is now a first-class diligence item, not a footnote. Known and unfixed at v1.0.3: ArticleResource/CollectionResource have no policies with strictAuthorization off (tenant members can CRUD articles and collections, including price, without a permission check); latent SVG stored XSS from image/svg+xml uploads to a public disk, live the moment storage:link runs; /user/profile breaks when social login is enabled; Password::default() is min-8 with no complexity or breach check. These are not "read the README" gaps — they are authorization and input-handling defects. This supports a prototype/internal tool decision and explicitly not a platform bet.
• Supply-chain and install reproducibility — a new, concrete risk. The version line is non-monotonic: v13.0.0 preceded v1.0.0, tracked the Laravel major, and Packagist still resolves it as highest, so composer create-project silently lands on the pre-fix v13.0.0 unless you pin 1.0.3. For a PM this is a roadmap item in its own right: any adoption must include a pinned version and a documented upgrade path, because "latest" is not the fixed version.
• Engineering-process signal has improved materially. 1,245 tests (7 added), live end-to-end verification, and unusually candid release notes naming the test (FortifyActionsTest::makeTeam()) that papered over the bug by creating the team and the role the code assumed. Combined with the AGENTS.md / triage-label / CONTEXT.md / docs/adr/ conventions already noted, the maintainer-communication and test-discipline story is the most credible thing in this repo — and it is copyable independent of the code.
• Not a decision driver for: pricing, catalog modeling depth, checkout correctness, tax, inventory semantics (the seeder sets inventory_count = 0 on every product, so the demo storefront ships sold out), fulfillment, or payments. Treat as substrate plus admin UI, not as a commerce feature set.
• Diligence flags for the roadmap review: zero dependents, ~190 stars, no support contract, no security disclosure process, and a repo that has already shipped an authentication bypass within its v1 line. Adopt only with a named owner for the fork and a security review budgeted up front.

When to Consider This Package

Consider it when:

• You are a PHP/Laravel shop and the deliverable is an internal tool, prototype, proof of concept, or first market test where an existing Filament admin (products, orders, invoices, customers) and a team/tenant model save real weeks.
• You want a reference implementation to read rather than a dependency to install — the authorization bug and its fix are a better multi-tenant authz teaching case than most documentation.
• You want agent-assisted development conventions (issue triage, ADRs, context docs) and a test-discipline example baked in from day one rather than retrofitted.
• MIT licensing matters — no procurement cycle, no vendor negotiation, no per-seat or revenue-share terms.
• You have engineering capacity to fork, pin to 1.0.3 or later, and harden: write the missing article_*/collection_* policies and their Shield permissions together, enable strictAuthorization, restrict upload MIME types and add storage:link hardening, fix the Socialstream/HasConnectedAccounts gap, and turn password rules up.
• You can assign a named security reviewer for the first transaction-adjacent milestone, not just the scaffold milestone.

Look elsewhere when:

• You need commerce primitives out of the box — cart, checkout, tax, shipping, multi-currency, promotions, inventory. Evaluate purpose-built PHP commerce platforms (Lunar, Bagisto, Aimeos, Sylius) or hosted/managed commerce. The v1.0.3 notes reinforce this: the missing pieces are the ones with money and PII attached.
• You need a support contract, SLA, security disclosure process, or a vendor who answers in a day. Zero dependents and no commercial backing mean you are the security team.
• You cannot pin dependencies reliably, or your build pipeline resolves "highest version" — in that state this package will silently install a pre-fix release.
• You are not on PHP/Laravel. There is no reason to import a framework preference for a skeleton.
• You are operating at scale where performance, multi-region, or high-volume transaction handling are load-bearing. Nothing here evidences that, and the authz model is still being corrected at the tenant boundary.
• You require a documented, auditable feature set before adoption. There is still no README-level capability statement; the release notes are the best available description of behaviour, which is a signal but not a spec.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed Laravel ecommerce application — now clearly more than a scaffold, since it ships an admin for products, orders, invoices and customers, a tenant/team model, and a storefront. It buys us weeks of scaffolding and an admin UI, plus a documented workflow for AI-assisted engineering and architecture decision records. The latest release fixed a serious authentication flaw where new registrants were attached to the merchant's own team with staff access — the fix is correct and verified, but the fact that it shipped within the v1 line tells you the security review is us, not them. It is also easy to install the wrong (pre-fix) version because of a broken version sequence, so adoption requires pinning. Recommendation: fund a four-to-six week spike against our next commerce initiative, with explicit go/no-go gates at (a) security review of the authz and upload paths and (b) proof that we get past week two faster than building from scratch.

For engineering: Treat this as a fork candidate, never a bare dependency, and pin 1.0.3 explicitly — composer create-project otherwise resolves the old Laravel-tracking v13.0.0, which predates the auth bypass fix. Read CreateNewUser::assignOrCreateTeam and canAccessPanel first; they are the clearest statement of the intended tenant model and of how it was violated. Then close the known issues in this order: article_*/collection_* policies plus matching Shield permissions (they must land together, since the Shield set has no such entries), strictAuthorization on, SVG upload rejection or sanitisation before anyone runs storage:link, the HasConnectedAccounts comment-out if social login is in scope, and Password::default() hardening. Also note RoleBasedRedirect is dead code inherited from a property-management app (all six targets 404) and config('permission.teams') is false, so roles are global despite team-scoped-looking code — delete or reconcile before building on top. The one thing worth lifting regardless of whether we adopt the code is the AGENTS.md / triage-label / CONTEXT.md / docs/adr/ workflow.

For finance/procurement: No licence cost, no vendor lock-in, no renewal. The real cost has changed shape: we are not just maintaining a fork, we are funding the security review that upstream has not had. Budget for a named owner indefinitely, no upstream to lean on for security patches beyond the Laravel ecosystem itself, and no disclosure process to notify us of the next issue like v1.0.3's. Compare that total against a commerce platform licence before approving anything beyond a time-boxed spike.