Application Laravel Package

Product Decisions This Supports

• Build-vs-buy on the application kernel — as a reference, not a dependency. mindy/application is the bootstrap/kernel layer of the MindyPHP micro-framework: application lifecycle, container wiring, request dispatch. Its PM value is scoping what a "minimum viable kernel" actually costs to build and own, benchmarked against Laravel, Symfony, or Slim. It is an input to the estimate, not the thing you ship.
• Dependency-risk triage rather than feature delivery. This package unlocks no user-facing capability — no auth, payments, search, or data layer. It enters a product conversation only through a dependency audit or an architecture spike, and the decision there is allow, pin, or remove, not prioritize against the roadmap.
• Fork-and-own staffing decisions. It is a [READ-ONLY] subtree split of the Mindy monorepo, so any patch or extension is a commitment to maintain a fork. That is a headcount and roadmap question for a PM, not a procurement line item.
• Framework bet evaluation. If engineering is evaluating lean PHP stacks, Mindy's per-concern repo structure signals its design philosophy, while 1 star and 0 dependents signal ecosystem risk. Both belong in the same decision memo, and the decision is made at the framework level — this component is downstream of that call.
• Enabling prototype or onboarding spend. A compact, MIT-licensed example of how a PHP application kernel is structured is genuinely useful for internal tooling, onboarding material, or a timeboxed spike — provided it is scoped as disposable.

When to Consider This Package

Consider it when:

• You are already inside the MindyPHP ecosystem, or running a deliberate spike to evaluate it, and need the Application component as a standalone Composer dependency.
• The goal is study, teaching, or a throwaway prototype where a minimal, readable kernel is the entire point and long-term support is irrelevant.
• MIT licensing is a hard requirement and a code audit has been completed — MIT permits commercial use, but it is not a security or maintenance guarantee.
• You can pin an exact version, vendor the code if necessary, and name an internal owner with an exit plan before the first commit.

Look elsewhere when:

• The system carries an SLA, handles regulated data, or needs a CVE response path. There is no published security policy, advisory feed, LTS branch, or visible release cadence, and a single-maintainer project is a bus factor you cannot contract around.
• You need a support contract, named vendor, or a procurement record that survives an audit — none of that exists here.
• You need batteries: routing, ORM, queues, auth, validation. Laravel or Symfony supply those plus a hiring pool; Slim supplies the thin layer with far more community validation.
• The team has no Mindy experience. With no tutorials, Stack Overflow coverage, or third-party integrations, every question becomes a read-the-source task, and that cost lands on engineering velocity rather than the license line.
• Vendor-risk policy sets a floor on maintainer count, dependents, or release history. This package clears none of those thresholds.

How to Pitch It (Stakeholders)

To executives: This is not a product dependency; it is a small, MIT-licensed application-kernel component from a micro-framework with effectively no adoption — one star, zero dependents, a single maintainer, and no visible support or security process. My recommendation is to keep it off any production path. Its value is as a readable reference artifact or as part of a bounded evaluation of MindyPHP as a stack. The license is free, but the real cost is support risk: if it breaks, we fix it ourselves, and we own that forever. There is no revenue upside and no capability we cannot get from a mainstream framework.

To engineering: It is small and readable, and that is the appeal — a compact example of how a minimal application kernel bootstraps a container and dispatches a request. Two constraints govern any real use. First, it is a read-only subtree split, so the canonical code and issue tracker live in the Mindy monorepo; patches go upstream, and if upstream stalls we are maintaining a fork. Second, treat it as vendored code with a named internal owner and an exact version pin, never as an upstream dependency we rely on for fixes. If a team wants it for a spike or an internal tool, that is a fine call — just log the owner and the exit plan at the same time. If anyone proposes it for a customer-facing service, the answer is no, and the reason is maintenance surface, not code quality.