Slate Bundle Laravel Package

Product Decisions This Supports

• API documentation delivery model. This package is a Symfony bundle that renders Slate-style, single-page, three-column API reference docs from within an existing Symfony application. Adopting it is a decision to ship static, hand-authored API docs as a first-class page of your product or developer portal — not to buy a hosted docs platform.
• Build vs. buy for developer-facing reference. It is the "build it cheaply, inside the stack we already run" option in the build/buy/host decision (vs. ReadMe, Stoplight, Redocly, Mintlify, or a docs-as-code pipeline). Useful framing for a roadmap item where the question is "do we need a vendor at all yet?"
• Framework-aligned tooling investment. Relevant only if the team has standardized on Symfony. (Note: this is a Symfony bundle, not a Laravel package — no Laravel service provider, no Laravel config publishing. A PM should not treat it as transferable across PHP frameworks.)
• Docs as a supported surface vs. a launch artifact. A cheap, self-hosted renderer lets a PM argue for shipping docs now (v1 reference for a public API or partner integration) without committing headcount or a recurring SaaS line item, while deferring the "real" docs product decision.
• Versioning and release process. Since Slate content is static and lives in the repo, it forces a decision about documenting API versions alongside code branches — often the more valuable product decision than the renderer itself.
• Where docs live in the customer journey. Embedding docs in the Symfony app enables auth-gated or internal-only docs (partner APIs, private beta surfaces) that a public hosted portal would expose.

When to Consider This Package

Consider it when:

• The application is Symfony (this is the hard gate; the package does not serve Laravel).
• You need credentialed or internal API reference docs more than a public marketing-style developer portal — e.g., partner integrations, a private beta API, or an internal platform team.
• You want zero recurring cost and self-hosting under an MIT license, with docs versioned in the same repo as the API.
• You already have — or can cheaply produce — the Slate markdown source (the hard part is authoring, not rendering; the bundle only wraps and configures the Slate output).
• The audience is small and known (dozens of integrators), so search, analytics, and interactive "try it" consoles are not yet decision-driving.

Look elsewhere when:

• You are on Laravel or framework-agnostic PHP. Nothing here transfers.
• You need an OpenAPI-first pipeline with generated reference plus interactive request consoles, code samples per language, and diffable specs. That is a Redocly/Stoplight/ReadMe class of problem.
• You need vendor support, SLA, uptime guarantees, SSO, analytics, or hosted search. A 4-star, 0-dependent bundle with a single maintainer carries maintenance and bus-factor risk that should not sit under a revenue-critical developer surface.
• Docs are strategic — a developer portal with onboarding, keys, changelog, and community. A static renderer becomes an architectural dead end you will migrate off.
• You need multi-language docs, deep search, or embedded API keys. Static Slate is weak here.

PM read on the signal: 4 stars, 0 dependents, and a low composite score describe a personal utility bundle, not an ecosystem-standard component. Treat it as a timeboxed spike or internal-only tool, not a platform bet. The durable asset is the Slate/OpenAPI source content, which stays portable if you later move to a hosted portal — a useful hedge to name explicitly.

How to Pitch It (Stakeholders)

For executives (30 seconds): We have a request to publish API reference documentation. There are two paths: a recurring SaaS developer-portal subscription, or a small open-source renderer we can drop into our existing Symfony app at zero license cost. The open-source option gets us a credible, professional-looking reference page for a pilot or internal/partner audience within days, and — critically — the documentation content we write is portable if we later upgrade to a paid portal. Recommendation: fund a one-sprint pilot, not a platform commitment, and revisit the buy decision once we have real usage data on the docs.

For engineering (the framing that gets a yes): It's a thin Symfony bundle over Slate — a static, three-column, single-page renderer that reads markdown from the repo, so docs ship with the code and review in the same PR. No new infrastructure, no vendor SDK, MIT license, fully self-hosted. The trade-off is explicit: it is a low-traffic community package (single maintainer, minimal adoption), it assumes Symfony, and it is not an OpenAPI-native or interactive docs tool. So we scope it to internal or partner-facing reference docs behind our existing auth, keep the source in markdown, and accept that a future migration to a hosted portal is a content move rather than a rewrite. If the requirement is a public, interactive, search-enabled developer portal, this is the wrong tool and we should say so up front rather than discover it after launch.