Prezet Laravel Package

Product Decisions This Supports

• Build vs. buy for content surfaces. Prezet lets the team ship a blog, changelog, docs section, or SEO landing content directly inside the existing Laravel app instead of standing up and integrating a separate CMS (WordPress, Ghost, Contentful, Sanity). That removes a vendor contract, a second deploy target, a second auth model, and an ongoing integration surface from the roadmap.
• Content marketing as a roadmap line item, not a platform project. Because posts are Markdown files in the repo with front matter, launching a marketing/content track becomes an engineering-sized task (days) rather than a platform-sized one (weeks plus procurement). This makes "invest in SEO-driven acquisition" a decision the team can actually schedule.
• SEO ownership stays in-product. Sitemap generation, canonical/meta handling, Open Graph imagery, and structured heading output are handled by the package rather than bolted on via a third-party SEO tool or hard-coded per-page logic. The v1.4.0 sitemap update is a direct example of this staying maintained upstream — a real (if unglamorous) recurring cost the team avoids owning.
• Version and upgrade planning. v1.4.0 adds Laravel 13 support, which de-risks planning the framework major upgrade: the content layer is confirmed forward-compatible before we commit the app-level upgrade, so it isn't a blocker in the migration critical path.
• Content-in-Git as a workflow decision. Editorial history, review, and rollback ride on the same PR process as code. This is a meaningful process decision (not just a technical one) — it suits teams where engineers or technical writers own the content, and it's a strong argument for developer-facing content (changelogs, release notes, technical docs) where accuracy is tied to a specific code state.
• Reduced ops and vendor-risk exposure. No external content database, no SaaS content API in the request path for public pages, no separate content-infrastructure incident surface. Relevant to any "reduce third-party dependency count" or cost-reduction initiative.
• AI-assisted development onboarding. The new "boost skill" (a Laravel Boost agent skill) means the package now ships guidance an AI coding agent can pick up. PM-relevant as a lever on onboarding time and on how much scaffolding work a new contributor or agent needs before shipping a post template or content type.

When to Consider This Package

Consider it when:

• The product already runs on Laravel and there is a real, funded intent to publish content — blog, changelog, docs, guides — in the next one to two quarters. Without that intent, this is shelfware.
• Content authors are engineers, technical writers, or anyone comfortable with Markdown and a pull request. The PR-based workflow is the package's core assumption; if authors can't work that way, the workflow cost lands on engineering as a permanent tax.
• Content volume is modest-to-moderate and read-mostly: dozens to low thousands of posts, infrequent edits, no complex editorial state machine.
• Content should be versioned alongside code — release notes, changelogs, versioned documentation, migration guides.
• SEO and page performance matter, and you want static-feeling public pages served from the app rather than a separate CMS origin.
• You want full control of presentation: views are Blade templates in your codebase, so brand and design changes don't require fighting a CMS theme layer.

Look elsewhere when:

• A non-technical marketing team needs a WYSIWYG editor, draft/publish permissions, granular roles, or an approval workflow. The Markdown-plus-PR model will become an engineering bottleneck and a source of organizational friction — this is the most common and most expensive mismatch.
• You need multi-author profiles, complex taxonomies, or heavy content-relationship modeling; that's a CMS's job, not a file-based blog's.
• Localization is a first-class requirement across many locales with translation management workflows.
• You need a digital asset management layer: large image/video libraries, rights metadata, automatic rendition pipelines at scale.
• Editorial preview, scheduled publishing with stakeholder sign-off, or A/B content testing are hard requirements.
• The stack isn't Laravel, or the team is planning to leave PHP — the value proposition collapses outside the framework.
• Content is the core product (e.g., a media business). Then content tooling deserves a dedicated buy decision, not a package decision.

Release-specific read on v1.4.0: this is a low-risk, adopt-worthy maintenance release. Laravel 13 support is the headline (forward compatibility, unblocks framework upgrades), the float implicit-conversion fix is a correctness bug fix that may explain data or formatting edge cases if we're already on 1.3.0, and the dependency and sitemap updates are routine hygiene. No breaking changes are indicated, so this should be treated as a routine upgrade and folded into the next maintenance window rather than scheduled as its own initiative.

How to Pitch It (Stakeholders)

For executives (one paragraph): Prezet lets us publish our blog, changelog, and documentation from inside the Laravel application we already run, using Markdown files stored in our codebase. The business consequence is that content marketing stops being a platform procurement project and becomes a normal engineering deliverable: no new CMS contract, no second system to secure and operate, no content API in the path of our public pages, and no vendor lock-in on our own words. It also keeps our SEO fundamentals — sitemaps, metadata, social preview images — maintained by the package rather than hand-built, and the new release confirms it supports the next major Laravel version, so it doesn't constrain our framework roadmap.

For engineering (the pitch): A first-party Laravel package that turns Markdown files with front matter into routed, SEO-complete content — sitemap, feeds, metadata, and Open Graph handling included — with Blade views we own and can restyle freely. Content lives in the repo, so review, rollback, and history are the Git workflow we already have. No external service, no queue dependency for public page rendering, no separate content database to back up or monitor. v1.4.0 is a low-risk upgrade: Laravel 13 support, a float-conversion bug fix, sitemap and dependency updates, plus an agent skill for Laravel Boost that reduces scaffolding work for new contributors.

The honest caveat to state up front: this is the right call only if the people writing the content are comfortable in Markdown and pull requests. If marketing needs a browser editor with roles and approvals, we should buy a CMS and budget for the integration instead — choosing Prezet and then discovering that mismatch is the expensive failure mode.