Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the content layer. Bolt answers the recurring "do we build a CMS admin again?" question with a configurable content model (contenttypes.yaml), routing, a working admin UI, and user/permission management under MIT. This is the decision it most cleanly supports: buying the commodity 70% (editing, permissions, media, templating) and spending engineering on the differentiators.
• Scope cuts on the roadmap. Content types, fields, and taxonomies are YAML configuration, not code. That converts "add a press release section" from an engineering sprint into a config change plus a theme template — a direct lever on backlog size and release predictability. Every content type you don't have to hand-build is capacity returned to the core product.
• Editorial self-service as a product bet. The built-in admin UI and permissions mean content ops own their workflow instead of filing tickets. That is measurable: count of "please add a field / change copy / reorder this" tickets per month is your before-and-after metric.
• Architecture fork: headless vs. full-stack. The genuinely consequential product decision is integration mode — Bolt as a headless content backend that your Laravel app consumes over HTTP, Bolt standalone beside it, or Bolt rendering with Twig with Laravel out of the request path. Headless preserves front-end control and lets the product use its existing design system and component library; full-stack is cheapest to run but makes shared domain logic and personalized/authenticated experiences much harder. Pick this before content modelling, not after.
• Extension-first as a policy. Custom console commands and Twig extensions cover most needs without patching core. That is a maintainability decision worth stating explicitly, given the release cadence is frequent and patch-heavy.
• Resourcing and skills. Bolt is Symfony, Doctrine, and Twig — not Laravel. It does not use Eloquent, service providers, facades, or Blade. Any plan that assumes a Laravel developer picks this up with no ramp is mispriced; budget a short ramp and treat "read Bolt's own docs" as a real onboarding task.
• Not a decision this supports well: anything requiring a large plugin ecosystem, first-party SaaS support, or a vendor who will sign an SLA. This is a self-supported open-source component with modest adoption — 592 stars and a low opportunity signal — so treat it as a dependency you own, not a platform you're subscribing to.

When to Consider This Package

Consider it when:

• You need a content-managed marketing or editorial surface (articles, docs, landing pages, product content) and are currently estimating weeks of engineering for an admin CRUD layer you don't consider differentiated.
• Your team is already fluent in PHP/Symfony or has at least one person who is. This is the single biggest predictor of success.
• The content model is reasonably stable and structural — content types with fields and taxonomies — rather than highly dynamic, user-generated, or workflow-exotic.
• You want an escape hatch: MIT license, Doctrine-backed storage you can query directly, and YAML schemas you can version-control and diff in PRs.
• You can accept self-support and a bump-heavy release cadence (6.1.9 is entirely Dependabot dependency churn — axios, undici, ip-address, shell-quote, and friends — with no features or breaking changes). If your org needs vendor accountability, look elsewhere.
• You're willing to run two caches and two stacks and own the operational reality of that: Symfony cache plus whatever HTTP cache sits in front, and frequent "the YAML change didn't apply" support load resolved by clearing caches.

Look elsewhere when:

• The team is Laravel-native with no Symfony depth and the product surface is small — a Laravel-native CMS or a hand-rolled admin over Eloquent will likely cost less in total, even if it costs more to build initially.
• You need rich, idiosyncratic editorial workflows (multi-stage approvals, complex scheduling, granular per-field permissions). Bolt's roles are a starting point, not a workflow engine.
• You need deep personalization or authenticated end-user experiences — that logic belongs in your application, which pushes you headless and shrinks the value Bolt adds.
• Ecosystem maturity matters — you want a large extension marketplace, hiring pool, or active third-party integrations.
• You require long-term vendor-backed support, security advisory SLAs, or a compliance story tied to a commercial entity.
• The content is transactional or highly relational product data rather than editorial content; you'd be fighting the content-type abstraction.

How to Pitch It (Stakeholders)

For executives: Bolt is a mature, MIT-licensed PHP CMS core that gives us content modelling, an admin UI, permissions, and templating out of the box. It lets us stop re-building content administration and redirect that engineering to what actually differentiates the product. The cost is a modest integration effort and our own operational ownership — no license fees, no vendor lock-in, and full data access via standard Doctrine storage. The main risks are honest: a small open-source community (roughly 600 GitHub stars), self-support, and a skill adjacency — it's Symfony, not Laravel — so we should fund a short ramp rather than assume zero learning curve.

For engineering: This is a Symfony/Doctrine/Twig codebase, not a Laravel package. Plan for contenttypes.yaml as schema-as-code, a single repository class as the seam between Bolt and our app, caching and invalidation owned in that layer, and a policy of extending rather than patching core. Expect frequent, low-drama patch releases dominated by JavaScript dependency bumps in the admin front end — so automate upgrades in CI, smoke-test a real content read, keep a rollback tag, and rebuild admin assets if we vendor them. Rebuild the bundles after upgrading, or we'll ship stale front-end code and chase a phantom regression.

Bottom line for the decision meeting: adopt it as a content layer, not a platform — headless behind a single service class if we value front-end control, full-stack if we value speed to launch. Model content types per concern (article, author, category), not per page, because that choice determines whether this stays pleasant at month six. If we can't name the person who owns Symfony in this codebase, we're not ready to adopt it.