Integrations Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for administrative UI. This package is scoped narrowly: it is the Filament presentation layer for an integrations domain module. It answers one question — "do we hand-roll admin screens for integration connections, credentials, and sync state, or inherit them?" — and nothing else. It does not supply the integrations engine, the provider SDKs, or the persistence layer.
• Ecosystem commitment, not library selection. Adopting this means adopting the Liberu modular stack (module-integrations + Filament + their module conventions). That is an architecture decision with a multi-year tail, not a dependency choice. Treat the evaluation as a platform bet, not a package trial.
• Feature-scoping input. If the parent module is in play, the adapter tells you what CRUD surfaces ship "free" (connection records, credential fields, status views) versus what you must still build (provider-specific auth flows, retry/backoff policy, webhook receivers, observability). Budget the latter explicitly — thin presentation adapters routinely create the illusion that a roadmap item is 80% done when it is 40% done.
• Roadmap risk weighting. Zero stars, zero dependents, and a single maintainer-org origin mean no community backstop. Any roadmap line item that silently depends on this package inherits a single point of failure. That is a scheduling risk you can price now and cannot price later.
• Procurement / legal gate. The license is NOASSERTION — GitHub could not identify a recognized license. For a commercial product this is a hard stop until clarified in writing. It is a five-minute question with a potentially deal-blocking answer, so surface it before engineering invests a sprint.

When to Consider This Package

Consider it only when all of the following hold:

• You are already committed to liberusoftware/module-integrations, or are actively evaluating the Liberu modular suite as a whole.
• Your admin surface is Filament (and a version compatible with this adapter's release line — the listed release date of 2026-10-26 is anomalous and should be verified against the actual tag history before you trust version constraints).
• You are comfortable with a zero-adoption dependency: no Stack Overflow answers, no third-party blog posts, no forked fixes, no one to ask but the maintainer.
• The license has been resolved to something your legal function accepts.

Look elsewhere — or build the equivalent in-house — when:

• You want an integrations admin UI for a standalone Laravel app. There is no value here without the parent module; a competent Filament developer reproduces these resources in roughly a day, with full control over provider-specific UX.
• You need provider depth (OAuth handshakes, token refresh, per-provider field schemas). Presentation adapters typically render generic forms; the interesting work is domain-side.
• You need support SLAs, security review artifacts, or a CVE response path. None are plausible at this adoption level.
• You are pre-product-market-fit and optimizing for reversibility. Coupling your admin layer to an unproven module ecosystem is a one-way door for a problem you can solve with ~200 lines of Filament.

Run it as a timeboxed spike (one to two days, throwaway branch) to harvest the data model and screen conventions, then decide whether to depend on it or reimplement. Reading the source is cheap; depending on it is not.

How to Pitch It (Stakeholders)

To executives: This is a small, unproven UI add-on from a niche modular-Laravel ecosystem — zero stars, zero downstream users, and an unresolved license. It is not a product decision, it is a build-versus-inherit decision worth roughly one developer-day either way. Recommendation: no commitment. We spend a short spike reading the source for design cues, and we do not put it on the critical path. The only thing that could change this is a licensing answer, which costs one email.

To engineering: If we are already inside the Liberu module stack, this saves us writing Filament resources for integration connection management. If we are not, it saves us nothing and costs us a dependency with no escape hatch — no forks, no issue history, no version guarantee we can verify. Assess it as a source of patterns first and a dependency second; the coupling risk sits with the parent module, not with this adapter.

Bottom line: high optionality, low urgency, near-zero switching cost in either direction — which is exactly the profile of a package you evaluate and then decline to depend on.