Seat Laravel Package

Product Decisions This Supports

• Build vs. buy for EVE Online org management. SeAT is an open-source, Laravel-native management platform for EVE Online corporations, alliances, and coalitions — character/ESI token management, member and HR tracking, assets, wallets, fittings, SRP, industry, and fleet tooling. If your product or community ops touches that domain, this is the strongest "buy/adopt" candidate versus building ESI integrations, token refresh, and permission models from scratch.
• Platform baseline / runtime currency. 5.0.2 raises the minimum supported PHP version. That is a compatibility decision, not a feature decision: it forces an explicit answer to "what PHP version do we run in production, staging, and CI?" and aligns SeAT with a supported, patched PHP line. If we adopt, we adopt the runtime floor with it.
• Hosted vs. self-hosted roadmap. 5.0.1 lowered deployment friction (default env settings); 5.0.2 constrains where it deploys. Any plan for per-tenant instances, ephemeral CI/staging, or a managed offering must now specify a PHP image/base version rather than inheriting whatever the host provides.
• Extension vs. fork. Do we build on SeAT's plugin/package surface (custom modules, scheduled jobs, ESI consumers) or fork the core? A maintained 5.x line shipping compatibility patches argues for extending — a fork freezes you on an unsupported runtime and forfeits security patches.
• Use-case prioritization. Concrete feature bets this unlocks: recruitment pipelines and alt/main mapping, participation and activity reporting, SRP claim workflows, asset and wallet auditing, doctrine/fitting compliance, industrial project tracking.
• Upgrade budgeting. Two patches on a young 5.x line — one config-hygiene, one runtime floor — indicates active maintenance but also churn. Supports a "track 5.x, pin to patch releases, read every changelog, budget majors" stance, and now a small recurring line item for keeping PHP current.
• Ops cost line item. Default env settings reduce per-install configuration; the PHP floor reduces "unsupported runtime" ambiguity. Net effect: lower onboarding time for new operators, but the install prerequisite list is now version-sensitive and must be documented and enforced (container base image, CI matrix, host package pins).

When to Consider This Package

Consider it when:

• Your users or customers are EVE Online players, and you need ESI-backed identity, roles, and org data without building the token/scope machinery yourself.
• Your stack is PHP/Laravel and your production, staging, and CI environments can meet SeAT's current minimum PHP version — and you have a routine for keeping PHP current, since 5.0.2 establishes that the project will move the floor.
• You need a broad, integrated surface (auth, HR, assets, wallets, fittings, industry) rather than one narrow feature, and the community plugin ecosystem covers your gaps.
• Self-hosting is acceptable and you can own the operational work: database, queue workers, ESI rate limits and error handling, backups, periodic upgrades, and runtime patching.
• You want a permissive open-source base you can extend privately without per-seat licensing.

Look elsewhere when:

• The product is not EVE-adjacent — the domain model (characters, corporations, ESI scopes, standings) is not a general-purpose identity or membership system.
• You are pinned to an older PHP version by a shared host, a legacy application, or an internal platform standard and cannot move on SeAT's schedule. Since 5.0.2 is a minimum-version bump, you cannot simply skip it and keep taking other fixes indefinitely.
• You require vendor SLAs, formal support contracts, or a compliance/audit posture that a community-maintained project cannot provide.
• Your team is standardized on another runtime (Node, Python, Go) and adopting a PHP/Laravel app would add a stack you cannot maintain.
• You only need one thin capability, such as reading a single ESI endpoint — a small library is cheaper to own than a full platform.
• You need deep, invasive customization of core behavior. Heavy forking forfeits the upgrade path and turns every upstream major into a merge project — and every runtime bump into a manual backport.
• You cannot absorb periodic major upgrades or periodic runtime-floor changes (the 4.x → 5.x transition implies the usual Laravel and dependency churn; 5.0.2 shows patch releases are not guaranteed to be runtime-neutral).
• Multi-tenant SaaS with strict isolation is the goal — SeAT is designed as an install-per-community application, not a tenant-partitioned platform.

How to Pitch It (Stakeholders)

For executives: SeAT is a mature, open-source, Laravel-based management platform for EVE Online organizations. It replaces a build-it-yourself integration project — identity, ESI token handling, member management, assets, wallets, and reporting — with an application we can deploy and extend. There is no license cost; our investment is operational (hosting, upgrades) and integration work. The latest releases are maintenance-only: 5.0.1 added default environment settings to shorten setup, and 5.0.2 raises the minimum PHP version so the project stays on a supported runtime. Neither adds user-facing capability, but 5.0.2 does mean our hosting and deployment images must be on a current PHP version. Recommendation: adopt as the base for EVE-adjacent features rather than building from zero, with a standing budget for tracking the 5.x line and keeping our runtime current.

For engineering: Standard Laravel application — Eloquent models, migrations, queue workers, scheduler. Extend through packages/modules and scheduled jobs rather than patching core. Expect to own ESI rate-limit handling, token refresh, and job retry semantics. 5.0.2 bumps the minimum PHP version; treat it as a compatibility release, not a drop-in: confirm the exact floor from the changelog/composer.json, align container base images, CI matrix, and host package pins, and sequence the upgrade behind your PHP upgrade rather than alongside a feature deploy. 5.0.1 (config defaults only) remains a safe pickup if you are on 5.0.0 and makes fresh installs and test environments more reproducible. Pin to patch releases, read the changelog before minor bumps, and treat majors — and runtime-floor changes — as planned projects with a staging rehearsal.

For product: Neither 5.0.1 nor 5.0.2 changes user-facing capability — do not schedule release notes or marketing around them. Their value is internal: faster environment provisioning (5.0.1) and a clearer, enforced runtime baseline (5.0.2). The product-relevant risk is deployment: an environment left on an older PHP version will fail to install or upgrade, so confirm the platform team's PHP roadmap before committing to a release cadence. Feature-facing opportunity sits in the plugin/extension layer (recruitment workflows, SRP, participation reporting), which is where differentiation should be built.