Core Laravel Package

Technical Evaluation

Architecture fit. flightphp/core is a micro-framework, not a Laravel component — there is no service provider, facade, or Composer package that drops into an existing Laravel application. Its architecture is a single front controller with a router, request/response abstraction, and a deliberately thin core extended through plugins. For a Laravel-centric PHP estate, that means Flight sits adjacent to the platform rather than inside it. The realistic fit is narrow-scope workloads: internal tools, small JSON APIs, webhooks, health/edge endpoints, and prototypes where bootstrapping Laravel would be disproportionate. The project's own guidance ("this is not a Laravel clone… avoid bloating the core") confirms it should not be evaluated as a Laravel substitute for domain-heavy applications.

Integration feasibility. Low friction to try, moderate friction to own. The MIT license and dependency-free core mean no license review, no transitive dependency audit, and no supply-chain surface from the framework itself. Deployment is a standard PHP-FPM/Composer artifact. Feasibility drops sharply where the product needs what Laravel provides out of the box: ORM and migrations, queues, auth/authorization, validation, events, scheduled tasks, and first-party observability hooks. Each of those becomes a build-or-buy decision, and re-implementing them is where a "simple framework" quietly becomes an expensive bespoke platform.

Technical risk.

• Data quality: the metadata shows a last release of 2026-10-27 (future-dated) and zero dependents against 2,895 stars. Both are inconsistent and must be verified against Packagist before any decision; the dependents figure in particular is a weak adoption signal if accurate and a data defect if not.
• Bus factor: a small-core, plugin-oriented project concentrates maintenance in a small maintainer group; plugin quality and long-term support are not governed by the core team.
• Compatibility floor: mandated PHP 7.4 support constrains the framework from modern language features and signals a conservative release cadence — good for stability, but it means the project optimizes for breadth of runtime support over modernity.
• Security defaults: thin frameworks generally ship fewer opinionated guardrails (CSRF, mass-assignment protection, output escaping conventions). Security ownership shifts explicitly to our engineers.
• Opportunity score (12.55) and overall score (47.05) read as "low strategic upside" — consistent with a mature, stable, low-growth utility rather than a platform bet.

Key questions.

1. Which of our services genuinely cannot justify Laravel's boot cost, and what is the measured delta?
2. Who owns security review and dependency hygiene for plugins we adopt, given the core is intentionally minimal?
3. Is the release/dependents metadata accurate, and what is the maintainer succession plan?
4. What is our exit cost if the project stalls — how much bespoke code would we have written by then?
5. Does adopting a second framework violate our platform standardization mandate, and if so, who grants the exception?

Integration Approach

Stack fit. Treat Flight as a tier-2 runtime alongside Laravel, not a replacement. Good candidates: single-purpose HTTP services, partner webhook receivers, internal admin utilities, static-adjacent endpoints, and CLI-adjacent tooling. Poor candidates: anything needing Eloquent-style domain modeling, background processing, multi-tenant auth, or a mature admin surface. Because it is dependency-free and framework-agnostic, a Flight service can live in the same monorepo, CI pipeline, and container base image as our Laravel apps without conflict.

Migration path. Movement is realistically one-directional. Laravel → Flight is a rewrite of framework-provided concerns and should be rejected for existing products. Flight → Laravel is feasible for a prototype that outgrows the micro-framework, but only if we constrain the prototype up front (thin controllers, no custom ORM, no bespoke event bus) so that the port is mechanical. Define that constraint as an explicit architectural rule, not a hope.

Compatibility. PHP 7.4+ floor is broader than most modern Laravel baselines, which helps on legacy hosts and constrained shared environments. Verify the target PHP version in our fleet against the framework's tested matrix, and confirm PSR-12/PHPStan level 6 alignment with our own static analysis gates — the project's tooling choices match common enterprise standards, which reduces CI integration work.

Sequencing.

1. Metadata and health verification (Packagist, release cadence, issue responsiveness, security advisory history).
2. Time-boxed spike: one non-critical internal service, two engineer-weeks, with success criteria stated in advance (boot time, LOC, dependency count, deploy simplicity).
3. Security and code-review checklist authored before the spike ships, covering input validation, output escaping, session/CSRF handling, and secrets.
4. Decision gate: adopt as tier-2 runtime, or archive the spike as a validated pattern only.
5. Only after a clean gate, document the approved use cases and prohibited ones.

Operational Impact

Maintenance. The dependency-free core is a genuine operational asset: minimal CVE surface, fast rebuilds, simple container images, and no framework upgrade treadmill. The counterweight is that everything Laravel would have maintained for us is now our code. Budget for that explicitly — the total cost of ownership is lower on infrastructure and higher on engineering hours, and the crossover point depends on how much framework surface the product actually needs.

Support. Community-supported under MIT, with no vendor SLA. Internal expertise must be seeded deliberately (at least two engineers, not one) so that support does not become a single-person dependency mirroring the upstream bus factor.

Scaling. Adequate for high-request, low-domain-complexity workloads — the minimal bootstrap is the point. It does not scale organizationally as well as it scales technically: as more teams adopt it, divergent plugin choices and homegrown conventions fragment the estate. If adoption spreads, publish an internal standard for routing, error handling, and plugin allowlisting, or the "simple and fast" benefit erodes into inconsistency.

Failure modes.

• Plugin abandonment: a critical extension goes unmaintained; mitigation is an allowlist and a policy of vendoring or forking with an owner assigned.
• Framework creep: the team rebuilds Laravel feature-by-feature inside Flight; mitigation is a written non-goals list and periodic LOC review.
• Security gaps from thin defaults: missing CSRF/escaping conventions cause an incident; mitigation is the pre-approved security checklist and a mandatory review for any public-facing endpoint.
• Silent divergence: undocumented local conventions across services; mitigation is a shared starter template and linting rules.
• Metadata-driven misjudgment: acting on the unverified release/dependents figures; mitigation is independent verification before the gate.

Ramp-up. Very fast for engineers with baseline PHP experience — hours to first working endpoint, days to productivity. The real ramp-up cost is unlearning: engineers fluent in Laravel will instinctively reach for facades, Eloquent, and containers that are not there, and will either over-engineer replacements or under-deliver on concerns Laravel handled invisibly. Pair the technical onboarding with an explicit "what you must now do yourself" checklist, and treat the first adopted service as the reference implementation that subsequent teams copy.