Burp Laravel Package

Product Decisions This Supports

• Build vs. buy, resolved toward "build on the framework": For any Laravel-targeted product, native routing plus middleware already covers query-string and URI-segment matching. This package does not unlock a capability we lack, so it should not shift a build-vs-buy decision.
• Dependency audit / "keep or kill": If zofe/burp already appears in a composer.json, this assessment supports removal. 18 stars, zero dependents, and a 0.3 quality score mean there is no maintainer community to inherit risk from — we would be the maintainers.
• Legacy consolidation roadmap: The package is most relevant as an incremental-migration artifact — a tiny router for PHP endpoints that exist outside Laravel and need to be folded into it later. That is a scoping input for a migration epic, not a roadmap feature.
• Prototype and internal-tool scaffolding: Acceptable for disposable internal tools, single-file webhook endpoints, and demo apps where code is expected to be thrown away before it reaches a customer-facing surface.
• Reference implementation for a routing spike: Reading the source is a cheap way to compare handler-resolution approaches (query-string vs. URI-segment) before committing to a custom router. This is a research input, not an adoption decision.
• Not a decision input for: authentication, authorization, API gateway, multi-tenant routing, or anything with a security boundary. The package's "Laravel filter system" concept predates the middleware pipeline most teams now depend on, and there is no evidence of a security response process.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a non-Laravel or pre-Laravel PHP codebase and need a router small enough to audit in an afternoon.
• The work is disposable or internal — prototype, spike, throwaway admin tool — and unmaintained code carries no production consequence.
• You explicitly need query-string routing semantics (?route=foo) alongside URI-segment matching, which modern routers often do not expose directly.
• You have accepted that you will own the code and have budgeted a fork, tests around request parsing, and a named maintainer.

Look elsewhere when any of the following hold:

• You are on Laravel 5+. Use the framework router and middleware. There is no gap to fill.
• You need PSR-7 / PSR-15 compatibility, middleware stacks, route caching, named routes, or route-model binding.
• You need security review, CVE response, or a maintainer who answers issues. With zero dependents and a low quality score, assume the package is effectively end-of-life.
• Your dependency policy forbids unmaintained packages — most organizations' do, and this one would fail that gate on maintenance signals alone.
• You need performance at scale. A simple segment matcher is fine for low route counts; it is not a reason to adopt, and the framework's cached router will beat it.

How to Pitch It (Stakeholders)

For executives: zofe/burp is a small MIT-licensed PHP router with negligible adoption — 18 stars and no downstream dependents. It is not a strategic dependency and does not belong on a build-vs-buy roadmap. Our recommendation is do not adopt for new work: the framework we already pay for includes a supported router at zero marginal cost, and adopting this would transfer maintenance risk to us for no product gain. The only spend we could justify is a short timeboxed spike if a team genuinely needs routing outside Laravel.

For engineering: Treat this as reference material, not a dependency. It shows a pre-middleware style of mapping query-string and URI-segment patterns to handlers, which is useful context when migrating legacy PHP endpoints into the framework. If we do fork it, we own it — that means tests around request parsing, a security read of the path handling, and a named owner on the team. Absent that commitment, close the ticket and standardize on the framework router; the migration path is the real work, and this package does not shorten it.