Ignition Laravel Package

Product Decisions This Supports

• Whether to invest in developer experience (DX) as a product surface. A good error page is a retention and onboarding lever, not cosmetics. Ignition turns a raw stack trace into a readable, themed page with application paths trimmed — the decision is whether your first-week developer experience is a differentiator or an afterthought.
• Build vs. buy for error presentation. Ignition is MIT-licensed and drop-in (Ignition::make()->register()). Buying means you ship a polished, maintained UI today instead of staffing a bespoke error page. It is not an error-tracking product on its own, so scope that decision separately.
• Encoding domain knowledge into self-serve remediation. The ProvidesSolution interface and HasSolutionsForThrowable solution providers let you attach a fix — "run migrations," "rotate the API key," "tenant is misconfigured" — directly to the exception. This is the highest-leverage PM decision here: it converts recurring support tickets into fixes the developer or user performs themselves. Prioritise which exception types deserve a written solution the same way you prioritise documentation.
• Support-ticket deflection and MTTR. Track the share of thrown errors that surface a solution, and whether those error classes stop generating tickets. That is the measurable business case.
• Roadmap of where debugging happens. Ignition offers a local-facing HTML error page plus optional production reporting to Flare. Deciding where a given class of error should be seen (local page vs. alerting pipeline vs. APM) is an architecture-and-spend decision you should own, not delegate to engineering defaults.
• AI-assisted remediation, with a cost and data-governance trade-off. The OpenAI solution provider is opt-in, sends error message, class, stack frame and limited context (not request payloads or environment variables), and supports a PSR cache to avoid repeat spend. This is a product call: faster first-response vs. per-incident cost, latency, and a third-party data flow to have signed off.
• Extensibility as a platform decision. Solution providers can ship from third-party packages, which means you can treat "solution-aware exceptions" as a contract your internal libraries honour.
• Documentation and support surface. The docs live on flareapp.io rather than in-repo; treat that external dependency as a known support risk for your own onboarding material.

When to Consider This Package

Adopt it when:

• You run a PHP application without a framework-native error page (plain PHP, legacy, or a CMS such as Drupal 10+, OpenMage, WordPress). This is the package's real sweet spot.
• You want consistent error reading across a polyglot PHP estate — the same visual language and solution model everywhere.
• You have recurring, well-understood failure modes worth encoding as solutions, and a team willing to maintain those providers.
• You need an off-switch and privacy controls you can document: shouldDisplayException, runningInProductionEnvironment, anonymizeIp, censorRequestBodyFields, and custom Flare middleware.
• Procurement friction must be zero — MIT, Spatie-maintained, changelog and dated releases (last release 2026-03-17) indicate active upkeep.

Look elsewhere when:

• You are on Laravel. Do not add this directly; laravel-ignition is already wired in for local development. Adding the base package is redundant work. Same logic for Symfony (use the bundle).
• You need production observability. Ignition is a presentation layer. If the requirement is alerting, grouping, release tracking, or APM/tracing, judge Sentry, Bugsnag, Rollbar, or Flare on those merits — Flare integration here is a convenience hook, not a selection reason.
• Your services are API-only. The value is an HTML page; JSON error consumers gain little.
• Data governance forbids sending stack traces to a third party (OpenAI or otherwise). Disable those providers explicitly rather than relying on defaults.
• Whoops or framework defaults are already good enough and no one is complaining. The pain has to be real.
• You need guaranteed multi-vendor support. One maintainer org (Spatie) plus a commercial upsell path is a concentration risk worth naming; note that direct dependent counts understate real usage because Laravel pulls the package transitively.

How to Pitch It (Stakeholders)

To executives: a small, MIT-licensed integration that shortens the loop between "something broke" and "here is the fix." The return shows up in three places: less time lost on onboarding new engineers, fewer repetitive support tickets when failures carry their own remedy, and faster recovery from incidents. Cost is engineering time, not licence fees; the only variable spend is optional AI-generated solutions, which are cached and can be capped.

To engineering: a better default. One registration call gets a readable, dark-mode-capable error page with application paths trimmed, plus an extension point — implement ProvidesSolution or a HasSolutionsForThrowable provider — so your team's tribal knowledge lives in the codebase instead of in someone's head. Solutions for common mistakes ship out of the box. Optional Flare hookup gives production reporting with the same client.

To security and compliance: the sensitive-by-default posture is explicit and configurable. The page is disabled outside local environments via shouldDisplayException / runningInProductionEnvironment. Data sent to any external service is bounded to error message, class, stack frame and limited context — request payloads and environment variables are excluded. IP anonymisation and request-body field censoring are one-line calls, and Flare middleware lets you intercept the report before it leaves. Ask for written confirmation of those settings in the rollout plan rather than assuming them.

Ask: approve a timeboxed spike — adopt the package in one non-Laravel service or legacy app, instrument two or three high-frequency exception types with solutions, and report back on solution coverage and ticket deflection before widening the rollout.