Reference Extension Laravel Package

Product Decisions This Supports

• Build vs. buy for CMS customization. This package doesn't add a feature — it lowers the cost of building one. If a roadmap item requires behavior Bolt doesn't ship (custom admin screens, content types, Twig helpers, API endpoints, migrations), this template is the starting point for the build side of that decision.
• Platform bet evaluation. If we're considering Bolt as our CMS, this gives us a realistic estimate of what "one custom extension" actually costs in engineering days — useful input to a spike, a proof-of-concept, or a go/no-go on the platform.
• Standardizing extension work across the team. As a canonical skeleton it settles recurring internal debates (directory layout, service registration, autoloading, test harness) once, so every subsequent extension starts from the same shape and reviews get faster.
• Scoping estimates. A reference implementation turns "custom CMS work: unknown" into a bounded number. That's directly useful for roadmap sizing, vendor negotiations, and deciding whether to staff customization internally or push it to an agency.
• Not a customer-facing decision. There is no user-visible capability here. Treat it as an internal accelerator and an architecture reference, not as a dependency that appears on a product surface.

When to Consider This Package

Consider it when all of the following hold:

• We are on Bolt (or actively evaluating it) and expect to write at least one custom extension — not just configuration or theme changes.
• The team is a PHP shop comfortable owning code with no vendor support path; we're prepared to fork and maintain.
• We want conventions more than functionality — the value is the shape of the code, not the code itself.
• We're comfortable that adoption signals are thin (5 stars, 0 dependents, 2025-12-04 release): fine for a template, disqualifying if we needed a supported library with an API contract.

Look elsewhere when:

• The application is Laravel, not Bolt. Bolt is Symfony-based; this scaffold's conventions won't map onto a Laravel codebase, and treating it as a Laravel package is a category error. For Laravel, use Laravel's own package skeleton and service-provider patterns.
• We need a maintained dependency. A template has no upgrade path and no release cadence to track; there is no security response, no changelog that matters, and no community to ask.
• Configuration or theming solves it. If the requirement is met by config and templates, an extension is overhead — say no.
• We need ecosystem depth. Low adoption means no third-party examples, no Stack Overflow coverage, and no hiring signal. Budget for internal expertise instead.
• We're not committed to Bolt. Building extensions deepens a platform bet; do this after the platform decision, not before.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed starting template for building custom functionality on top of Bolt. It isn't a feature and it doesn't ship to customers — it's a cost reducer. Its practical effect is to cut the estimate for our first CMS customization and to make that estimate credible, which is exactly what we need to decide whether to build on Bolt, buy a plugin, or not do the work at all. Risk is close to zero: it's scaffolding we copy, not a dependency we install and must maintain.

For engineering: It's a reference skeleton — layout, registration, autoloading, test setup — so we argue about architecture once instead of per extension. We fork it, own it, and add it to our internal conventions. Two caveats to accept up front: it's Bolt/Symfony, not Laravel, so don't try to reuse it across a Laravel codebase; and with 5 stars and zero dependents, there is no support contract and no community to lean on — we are the maintainers. Approve it as an internal accelerator with named ownership, not as a platform dependency.