Bootstrapi Laravel Package

Product Decisions This Supports

• Build vs. buy vs. copy: This is a project skeleton, not a consumable library — there is no composer require value here. The only realistic decision it informs is "do we copy this structure into a new repo," which is a template decision, not a dependency decision. Treat any evaluation as a time-boxed spike (a few hours), not a procurement.
• Framework strategy for small services: It is useful prior art if the team is weighing "full Laravel vs. minimal-footprint PHP API." The stack (Slim 3 routing + standalone Eloquent + Zend-ACL) is a concrete example of how a ~no-framework JSON API gets assembled, including the glue code most teams underestimate: error handling, CORS, auth wiring, DI container setup.
• ACL/authorization design reference: The Zend-ACL integration is worth reading as a comparison point against Laravel's Gates/Policies and role packages (spatie/laravel-permission). Useful input to an authorization-model design discussion, not an implementation to inherit.
• Roadmap impact: none. With 0 dependents, 86 stars, and a dependency graph built on end-of-life components, this does not justify a roadmap line item or an architecture change. It should not be cited as validation for a technical direction.
• Honest scope correction: This is not a Laravel package. It is a Slim 3 skeleton with Eloquent bolted on. If the question on the table is "what do we add to our Laravel app," this package is out of scope; if the question is "should we run a non-Laravel microservice," it is a data point.

When to Consider This Package

Consider it only when all of the following hold:

• The team has deliberately chosen Slim (or a non-Laravel micro-framework) and wants Eloquent's query builder and models without pulling in the full framework.
• You need a starter repository you will own and fork outright, not a maintained upstream you expect to pull updates from.
• The target runtime is pinned to PHP 7.x and you accept that constraint permanently, or you are budgeting an immediate rewrite of the framework layer.
• Someone on the team will read the source as a reference implementation — CORS, JWT, error shapes, ACL wiring — and then write your own version.

Look elsewhere when:

• You are a Laravel shop. laravel new already ships routing, Eloquent, validation, Sanctum, API resources, and Gates/Policies with maintained dependencies. Adopting this skeleton means trading a supported framework for a bespoke stack to save a few megabytes — a bad trade.
• Maintenance and security posture matter. Slim 3 is end-of-life, Zend-ACL is abandoned (migrated to Laminas), and the project has a single maintainer with minimal community surface. For anything touching authentication or authorization in production, that is disqualifying.
• You need PHP 8.1+ or long-term upgrade paths. You will be doing the upgrade work yourself, alone, with no upstream.
• You need support, SLAs, or a hiring pool. 86 stars and 0 dependents means no Stack Overflow corpus, no third-party tutorials, and no candidates who have seen it.
• You are evaluating on dependency health. The vendor name in the package metadata (pmurkin/bootstrapi) does not match the repository owner (kot13/bootstrapi) — confirm what is actually installable from Packagist before spending any time on it.

How to Pitch It (Stakeholders)

For executives: This is a small, single-maintainer boilerplate project for building PHP JSON APIs without a full framework. It is not something we would adopt as a dependency — it is a code sample. The components it is built on (Slim 3, Zend-ACL) are end-of-life or abandoned, so adopting it would create a security and maintenance liability we would have to own indefinitely. Recommendation: no adoption. At most, one engineer spends half a day reading it as a reference during our API-architecture discussion, at effectively zero cost and zero ongoing commitment.

For engineering: Read it, don't fork it as a foundation. The value is in seeing how routing, ORM, ACL, and error handling fit together in a ~minimal PHP API — particularly if we ever discuss a non-Laravel service. The costs are concrete: EOL Slim 3, abandoned Zend-ACL, no upstream to merge from, and a single maintainer. For any new API inside our Laravel estate, laravel new plus Sanctum and Policies gives us the same capabilities on maintained dependencies, with a hiring pool and a support community behind it. If someone wants to prototype the Slim approach, timebox it and treat it as throwaway.