Web Laravel Package

Product Decisions This Supports

• Build vs. extend/fork for EVE Online corp and alliance tooling: eveseat/web is the presentation layer of SeAT, so the decision it informs is whether to extend an existing SeAT deployment or build a bespoke admin/portal from scratch — not whether to buy a standalone component.
• Feature and roadmap scoping: if the product includes member dashboards, API key management, fleet/asset/wallet views, or role-based access UIs, this package serves as a reference for the domain's expected workflows and information architecture.
• Reuse assessment for Laravel admin UI: it exposes routes, controllers, Blade views, and permission middleware patterns a team could mirror to accelerate a greenfield Laravel interface.
• Ecosystem commitment: choosing it signals investment in the SeAT plugin/module ecosystem, which should be weighed against long-term maintenance burden and GPL-2.0 obligations.
• Prioritization input: because its value is domain-specific UI depth rather than generic functionality, it pushes the roadmap conversation toward "do we need EVE-specific depth, or a general-purpose admin panel?"

When to Consider This Package

Consider it when:

• You already operate SeAT and want to build or customize member-facing modules without rewriting the UI layer.
• You're building an EVE Online-adjacent tool and want a proven reference for auth, API-key, and permission flows.
• Your project is GPL-2.0 compatible and can absorb copyleft obligations.
• You're on a Laravel/PHP stack and want to evaluate the existing ecosystem before committing engineering time.

Look elsewhere when:

• You need a general-purpose web interface or admin panel — this is tightly coupled to SeAT's core packages and domain models.
• You're shipping proprietary or SaaS software; GPL-2.0 will constrain distribution and linking.
• You need a stable, widely adopted dependency — ~26 stars and its status as a split-out component of a larger monorepo are meaningful maturity and support signals.
• Your team isn't already invested in SeAT — the web layer alone delivers little without the core.

How to Pitch It (Stakeholders)

For executives: this isn't a general-purpose library; it's the UI layer of a niche open-source community-management platform. The strategic question is whether we extend SeAT or build our own admin experience. Direct cost is low (free, GPL-2.0), but so is portability — the real decision is ecosystem commitment versus bespoke build. Recommend a short spike prototyping one module on SeAT before committing roadmap.

For engineering: treat it as a reference architecture and integration surface, not a dependency. It shows how SeAT wires routes, controllers, Blade views, and permission middleware on Laravel — useful if we build a similar admin UI. Flag the GPL-2.0 license early so legal can weigh in before any code is copied or linked. Given the low star count and monorepo-split nature, pin versions, expect limited external support, and budget time for reading the core SeAT source.