Filament Pos Laravel Package

Product Decisions This Supports

• Channel expansion bet: Decide whether to test in-person selling alongside the existing Laravel/Filament commerce stack using an admin-native register, rather than commissioning a custom cashier UI or buying a separate SaaS POS. The package shortens time-to-demo, which is the cheapest way to learn whether an offline channel deserves roadmap spend.
• Build vs. buy vs. fork: Position it as an accelerator, not a platform. Compare three options — adopt the package, build the register internally on Filament resources, or fork and own — and price the real cost of each in integration, hardware support, payment/inventory hardening, security triage, and upgrade maintenance. The MIT license is the cheapest part of the decision.
• Ecosystem dependency as a strategic question: With 71 stars, 0 dependents, and a future-dated release marker, this is a prototype-grade dependency. The decision it supports is "do we invest in the TomatoPHP/Filament plugin ecosystem," not "which POS do we standardize on."
• Ecommerce/POS convergence: If the product already runs TomatoPHP's Ecommerce Builder, evaluate whether POS and online can share one catalog, order, and inventory source of truth — or whether separate systems are safer for reconciliation and accounting.
• Feature prioritization through workflow audit: Separate advertised capabilities (cart, barcode search, tender, receipts, reports) from production must-haves (returns, discounts, tax handling, cash management, permissions, inventory sync, reconciliation). Only the second list should drive scope.
• Data ownership and exit strategy: The single highest-value product question is where POS sales are written — into ecommerce_orders or into pos_* tables. This determines whether we can extract data, swap the register later, or fork cleanly. Answer it before funding a pilot.
• Decision-gate design: Define spike and pilot exit criteria up front so the org chooses deliberately between adopt, fork-and-own, internal build, or stop — instead of drifting into production because the demo looked good.
• Hardware scope decisions: Receipt printing, barcode scanning, and cash drawers must be proven on target hardware in week one. If they can't be, the fallback product scope is "order entry with emailed receipts," and the business case should be priced accordingly.

When to Consider This Package

Consider it when:

• You are already on Laravel + FilamentPHP and want an admin-native POS starting point instead of a separate SaaS terminal.
• The immediate need is a spike, internal store, pop-up, showroom, event sales, or phone-order entry — learning, not revenue-critical scale.
• You already use TomatoPHP's Ecommerce Builder and want to test unified online/offline catalog and order flows.
• You have engineering capacity to audit migrations, permissions, checkout transactions, and refund/payment behavior, and to own production hardening.
• You are targeting one to a handful of registers, not high-volume multi-terminal multi-location retail.
• You accept MIT licensing with eyes open: "free" still carries integration, support, security, and fork-maintenance cost.

Look elsewhere when:

• POS is core revenue infrastructure requiring offline-first operation, certified hardware, audited payments/tax, or multi-location scale.
• You need mature documentation, community support, SLAs, or proven production references — 0 dependents is a genuine validation gap, not a rounding error.
• Your stack isn't Filament-based, or you need a headless/API-first POS rather than a panel plugin.
• Must-have workflows (returns, discounts, tax, cash management, permissions, inventory sync, reconciliation) can't be verified in code.
• Card-present payments, receipt printing, or scanning are hard requirements and can't be proven on real hardware early.
• The organization can't absorb vendor risk or would need deep forks that make upgrades impractical.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed accelerator for testing in-person sales inside the Filament admin we already run. It can compress time-to-demo and tell us whether a POS channel earns roadmap investment, but it is not a proven production platform: adoption signals are thin (71 stars, zero dependents), and payments, inventory integrity, hardware, and support are unvalidated. Recommend funding a short, bounded spike with an explicit decision gate — not a platform commitment.

For engineering: Treat it as a Filament-native POS scaffold rather than a finished commerce engine. It sits on top of Ecommerce Builder and a specific Filament major, so pin Filament, Ecommerce Builder, and this package as one upgrade unit and upgrade them together on a branch. Audit the migrations for data ownership, confirm checkout uses a transaction with row locking or atomic stock decrement, isolate payment and inventory edges behind your own adapters, export rather than query POS tables, and seed cashier vs. manager roles explicitly. Prove receipt printing and barcode scanning early. Keep the register layer replaceable so the back office survives if the terminal doesn't.

For product leadership: Use this package to buy learning time, not to skip due diligence. Frame the spike around five questions — where sales data lands, what the payment story actually is, whether hardware works, what happens on flaky store Wi-Fi, and whether two terminals can oversell. Set explicit criteria for adopt / fork / build / stop before the spike starts. The package is most valuable when it de-risks a market test; it is most dangerous when a working demo is mistaken for a production-ready system.