Slim Starter Laravel Package

Product Decisions This Supports

• Framework strategy for a new PHP service: Slim vs. Laravel. This package is a worked example of what a Slim-based MVC (and HMVC) application skeleton looks like, which is useful for arguing the trade-off: Slim gives you routing + PSR-7 and little else, so a starter like this is effectively "Laravel's structure without Laravel's ecosystem." Use it to decide whether your team wants a batteries-included framework or a hand-assembled stack.
• Build vs. buy for scaffolding. The real question this surfaces: do we adopt a third-party skeleton, fork one, or write our own composer create-project template? A 2014-era starter with zero dependents argues strongly for owning your own template — it's ~a day of work and you control the upgrade path.
• Module boundary / team topology decisions. The HMVC angle (controller-level module nesting) is a specific architectural bet. Worth evaluating only if you have a concrete requirement for independently addressable feature modules — otherwise it's complexity you inherit for free from someone else's opinion.
• Prototype-vs-production gating. Useful input to a "time-boxed spike only" decision: acceptable for a throwaway demo or internal proof-of-concept where you delete the repo afterward; not a defensible choice for anything with a support commitment.
• Roadmap risk register entry. With last release 2014-05-26, zero dependents, and no evidence of maintenance, this is a data point for your dependency policy: define an explicit rule that dependencies with no release in N years require an owner and a fork plan before adoption.

When to Consider This Package

Consider it when:

• You are already running Slim 2 in-house, need a reference for conventional MVC layout, and want to read (not install) someone's structure.
• You need a disposable internal demo or teaching artifact for a few days, with no production exposure.
• You are doing competitive/architecture research and want concrete examples of HMVC implemented over Slim.
• You are willing to vendor/fork the code and own it entirely.

Look elsewhere when:

• Any production, long-lived, or internet-facing use. The last release is 2014; that predates Slim 3 and Slim 4, and almost certainly assumes PHP 5.x. Expect incompatibility with modern PHP 7.4/8.x, no PSR-7/PSR-15 alignment, and no security-patch path.
• You need a maintained skeleton. Prefer Slim's own official skeleton, the Slim 4 docs' recommended structure, Laravel/Symfony for batteries-included needs, or Laminas/Mezzio if you want a maintained modular-middleware stack.
• You need community support. Zero dependents and a single-maintainer history means no Stack Overflow surface, no CVE response, no upgrade guides.
• Your team's stack is Laravel. Mixing a Slim 2 skeleton into a Laravel shop creates two idioms, two upgrade cadences, and no shared tooling — negative value.
• You need auth, queues, admin panels, or ORM out of the box. You will rebuild all of it; cost that against the "free" starter.

How to Pitch It (Stakeholders)

One-liner: A well-known but abandoned 2014 starter application for the Slim PHP micro-framework — valuable as an architectural reference, not as a dependency.

For executives: Not a recommended adoption. It has ~285 GitHub stars (interest, not adoption), zero dependent packages, and no release in over a decade. There is no vendor, no support contract, and no security response. The only defensible uses are research and short-lived prototypes. If someone proposes it for a product, the honest framing is: we would be adopting an unmaintained codebase and inheriting its upgrade debt on day one.

For engineering: Read it for the MVC/HMVC layout ideas; don't composer require it. It targets the Slim 2 era and will fight modern PHP and modern Slim. If the HMVC module pattern is genuinely attractive, we can implement that pattern ourselves in Slim 4 or Laravel modules in a few days, with tests and an upgrade path. Recommended action: harvest patterns, own the template.

Decision requested: Approve a "reference only" classification, and approve a small spike to evaluate Slim 4's official skeleton vs. Laravel for the actual workload — that's the decision with real downstream cost, and this package is a useful exhibit in that conversation rather than a candidate itself.