Framework Laravel Package

Product Decisions This Supports

• Build vs. buy for content surfaces. HydePHP is a Laravel-native static site generator: Markdown/Blade in, pre-rendered HTML out. It answers the recurring "do we spin up a CMS, a Node-based SSG, or just write a small internal generator?" question for docs sites, changelogs, blogs, marketing microsites, and developer portals — with no license cost (MIT).
• Toolchain consolidation. For a PHP/Laravel shop, adoption removes a whole parallel ecosystem (Node, npm, a second build pipeline, a second CI image, a second set of security patchers) from the roadmap. That's a platform-standardization decision, not just a library pick.
• Roadmap sequencing for internal platform teams. If documentation is a bottleneck (API docs, onboarding docs, release notes), HydePHP makes "docs-as-code" cheap enough to fund in a single sprint rather than a quarter. It supports prioritizing content velocity work that would otherwise be deprioritized behind product features.
• Use cases that fit well: internal knowledge bases and handbooks; open-source project sites and package documentation; product changelogs and release notes; SEO-sensitive marketing pages that benefit from static output and near-zero hosting cost; prototypes and microsites that may later grow into a full Laravel app (same language, same templating, same conventions).
• Hosting and infrastructure economics. Static output means CDN/object-storage deployment instead of a runtime PHP container — a cost and attack-surface decision that shows up in TCO models and security review, not just in code.
• Vendor and skills decisions. It lets you staff content tooling with existing Laravel engineers instead of hiring frontend-specialist SSG talent — relevant to hiring plans and to how you scope contractor work.
• Risk register input. Package signals (37 stars, 0 dependents, a single-maintainer-shaped footprint) should drive an explicit internal-ownership commitment before it becomes load-bearing in the roadmap.

When to Consider This Package

Consider it when most of these are true:

• You are already a Laravel/PHP team. The value proposition is largely "no new language, no new build system." Outside that context the trade-off inverts quickly.
• The content is documents, not an application. Blogs, docs, guides, changelogs, landing pages, team handbooks — content that is authored in Markdown or Blade and changes on a deploy cadence.
• You want static output. Fast page loads, trivial CDN hosting, no database or queue to operate, and a small security surface for public-facing brochure content.
• You value convention over configuration. The framework makes structural choices for you (directory layout, page models, build pipeline). That is a feature for a small team and a constraint for a team with strong opinions.
• Content sites can live next to your app. Being able to colocate a docs site in the same repo, using the same Blade components and the same CI, is a real maintenance win.
• You can absorb the maintenance relationship. Budget a named internal owner and a plan to pin versions and review upgrades.

Look elsewhere when:

• You are not a PHP shop. The whole argument collapses; Astro, Eleventy, Hugo, or Next.js will have better community support and hiring pools for your team.
• You need a mature ecosystem. 37 stars and effectively no dependent packages means a thin plugin ecosystem, few Stack Overflow answers, and little third-party tutorial coverage. If your team learns primarily from community content, expect friction.
• The site is a CMS-backed application. Multi-author editorial workflow, granular roles/permissions, scheduled publishing, preview environments for non-technical editors, and localization pipelines are not the sweet spot — a headless CMS plus a renderer is the safer fit.
• You need heavy client-side interactivity or a rich component library. Static-first, PHP-templated output is not the right substrate for app-like experiences.
• You require vendor support, SLAs, or long-term deprecation guarantees. MIT and a small maintainer base means no commercial backstop; the bus-factor risk is yours to underwrite.
• Content scale is large and editorial velocity is high (thousands of pages, many daily contributors). Build times and authoring ergonomics should be benchmarked before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): HydePHP is a free, MIT-licensed static site generator built on Laravel. It lets our existing PHP engineers ship documentation, changelogs, and marketing pages as plain pre-rendered HTML — no new language, no Node toolchain, no CMS contract, and hosting costs that round to zero via CDN. The strategic case is consolidation and speed: content work gets done by the team we already have, in the stack we already operate, instead of adding a parallel frontend ecosystem to secure, patch, and hire for. The honest counterweight is ecosystem maturity — the project has a small community and no commercial backstop — so the recommendation is to adopt it deliberately for a bounded, non-critical content surface, with a named internal owner, pinned versions, and a documented exit path, rather than as an org-wide standard on day one.

For engineering leadership: This is a small, opinionated framework that trades flexibility for convention. Blade and Markdown replace JSX and MDX; the build pipeline is PHP; deployment is a directory of static files. That means fewer moving parts in CI, no runtime container for public content, and one less dependency tree to audit. The cost is ownership: we inherit upgrade diligence and any customization we layer on. Scope the first adoption to something we could rebuild in a week if needed — internal docs or a product microsite — and treat broad standardization as a second-phase decision gated on that pilot.

Ask: Approve a timeboxed pilot (one content surface, one owner, 2–3 sprints), with a review checkpoint covering build ergonomics, authoring experience, and an explicit kill criterion.