Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the HTTP layer. Flight is a routing/dispatch core, not an application platform. The decision it informs is narrow and useful: do we pay the Laravel/Symfony complexity tax for this service, or ship a thin router we fully understand? For small APIs, internal tools, webhooks, and single-purpose services, Flight is the "buy the 200 lines you'd otherwise write badly" option.
• Greenfield microservice and edge-service scoping. Because core is dependency-free and optimized for PHP 7.4+, it fits services that must stay small: low memory footprint, no container boot cost, trivially deployable on shared hosting or constrained PHP-FPM pools. This is a hosting-cost and cold-start decision as much as a code decision.
• Roadmap sequencing for platform teams. Flight's own governance model (core stays minimal; features land as plugins) is a template. If your roadmap has "build internal framework conventions," Flight lets you adopt the router and own the rest, rather than adopting someone else's opinions wholesale.
• Prototype-to-production gating. It supports the "can we validate in two weeks" decision: no ORM, no queue, no auth stack to learn. The PM trade-off to record explicitly is that anything beyond routing is your build item, not a config flag.
• Legacy PHP modernization. A credible intermediate step for teams on hand-rolled index.php routing who cannot justify a framework migration. It preserves PHP 7.4 compatibility, which matters for older infrastructure.
• Vendor and dependency-risk posture. MIT license, no transitive dependencies, small surface area = favorable for procurement and security review in regulated or air-gapped environments, where "install 80 packages" is a blocker.
• Platform-fit caveat that changes the decision: this is not a Laravel package — it is a competing micro-framework. If the existing product is Laravel, Flight's realistic role is sidecar services, CLI-adjacent tooling, or prototypes, not a drop-in library. Treat "Laravel/PHP package" framing as a category error to correct before it reaches a roadmap.
• Signals to verify before commitment: ~2.9k stars indicates a real but modest community; "0 dependents" is almost certainly a measurement gap rather than an adoption fact; the listed last release date (2026-10-27) is forward-dated and must be confirmed against the repo. None of these is disqualifying, but a PM should not present unverified numbers as adoption evidence.

When to Consider This Package

Consider it when:

• The deliverable is a small, bounded HTTP surface — REST/JSON API, webhook receiver, internal admin tool, health/status endpoint, or a service behind a gateway.
• Latency, memory, and deploy simplicity are explicit requirements, or you are on constrained/shared PHP hosting.
• Your team is small and senior enough to own the pieces Flight omits (validation, DB access, auth, config, logging) without a framework holding their hand.
• Dependency minimization is a compliance, security-review, or supply-chain requirement.
• You need PHP 7.4 compatibility, or must support a mixed 7.4/8.x fleet.
• You want a deliberately reversible choice: thin routing code ports cheaply if the service later outgrows it.

Look elsewhere when:

• You need batteries included — ORM/migrations, queues, auth scaffolding, mail, events, admin panels. Rebuilding these on Flight is a hidden multi-sprint cost that dwarfs any savings.
• The product is a long-lived, multi-team monolith with many contributors. Convention and shared structure beat minimalism at that scale.
• Hiring and onboarding velocity dominate. Laravel/Symfony talent depth is a real, quantifiable advantage; a niche framework raises ramp time and bus factor.
• You need a supported commercial vendor, LTS guarantees, or a large first-party plugin ecosystem.
• The workload is heavy async/queue-centric (look at Laravel + Horizon or a non-PHP runtime) or needs first-class WebSockets/streaming.
• An existing Laravel codebase is in play — adding a second framework for a feature is a maintenance and cognitive-load cost with no offsetting benefit.

Due diligence before adoption: confirm release cadence and maintainer concentration; verify the dependents figure and recent commit activity directly; review the plugin ecosystem for the three things you'd otherwise build (DB, auth, validation); and check that PHPStan level 6 + PSR-12 enforcement in CI is actually running, since that is the quality proxy for a project this size.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating FlightPHP as the HTTP foundation for a small, well-bounded service rather than adopting a full framework. The case is cost and risk containment: MIT-licensed, zero dependencies, no vendor lock-in, and a footprint small enough to pass security review quickly and run on the infrastructure we already pay for. The trade-off is explicit and bounded — Flight gives us routing and extension points, and we consciously own everything else. It is not a fit for our multi-team core product, and I am not proposing it there. Decision requested: approve a time-boxed pilot on one non-critical service, with a defined exit path (thin routing code is portable) if it underperforms.

For engineering — the substance:

• It is a micro-framework, not a Laravel package. Treat it as an alternative to Laravel/Symfony for narrow services, not an addition to an existing Laravel app.
• Core is dependency-free, PHP 7.4+, performance-first by stated project policy. Extension happens through plugins, not core growth — so architectural discipline is on us.
• Quality signals are reasonable for the size: PHPUnit, PHPStan level 6, PSR-12 via PHPCS, documented contribution rules. That is a team that will accept a strict PR standard.
• What we must budget for explicitly: validation, persistence/migrations, authn/authz, config, logging, error handling, and observability. Name an owner and a sprint estimate for each before we commit.
• Risks to log: modest community (~2.9k stars), unclear real-world dependent count, likely small maintainer pool, and unverified release metadata. Mitigation is architectural, not contractual — keep business logic out of framework-specific code so the router is replaceable in days, not quarters.
• Pilot exit criteria: a working service in ≤2 sprints, no framework-specific coupling in domain code, and a written list of what we had to build ourselves versus what a full framework would have provided. If that list is longer than the sprint savings, we stop and migrate to Laravel while the code is still cheap to move.