Nova Page Laravel Package

Product Decisions This Supports

• Build vs. buy for "CMS-lite." This package creates a third option between hand-rolling a page admin and licensing a full CMS (Contentful, Sanity, Statamic, Storyblok). If the requirement is "let marketing edit copy, headlines, and images on static pages without a deploy," nova-page delivers buy-level cost with build-level fit because it lives inside the Laravel/Nova admin we already operate. It is the cheapest credible answer to the question, and it defers the platform decision rather than foreclosing it.
• Roadmap sequencing. It converts a "self-serve content" milestone from a full engineering sprint into a template-design and configuration task. Marketing, campaign, legal, and about pages can ship as a fast-follow instead of competing with core product work for the same sprint capacity.
• Ticket deflection as a measurable outcome. Routine copy, headline, hero image, and localized-copy changes move off the engineering backlog and onto content owners. Instrument it: count page-change tickets and deploy frequency before and after adoption. That delta is the business case, and it also sizes the threshold at which a fuller CMS becomes justified.
• Localization expansion. Locale-aware content and per-locale slugs mean a localized brochure or regional marketing site can launch without standing up a second content platform — avoiding a vendor evaluation, procurement cycle, and legal review that would otherwise land on the roadmap.
• Stack consolidation. Content management stays inside the existing Nova surface: no second login, no second vendor relationship, no separate SSO integration, and no parallel permission model to audit or reconcile with existing roles. For a small team, the operational savings here often exceed the license-cost savings of a free package.
• Admin platform upgrade path. Nova 5 compatibility in v0.4.0 removes a scheduled "upgrade Nova or keep the page editor" fork from the roadmap and extends the package's useful life by at least one Nova major. This is the most decision-relevant fact in the release — but confirm it is additive (Nova 4 and 5 both supported) rather than replacing Nova 4, because our own Nova version determines whether the upgrade is optional or forced. Validate this at the composer constraint level on day zero, before it becomes a surprise during a routine dependency update.
• Scope boundary decision (the important one). This is a page editor, not a content platform. Adopting it is an explicit statement that our content needs are structured and bounded: a known, developer-defined set of page types and content blocks, edited by a small content team at modest volume. Record that assumption in writing. It is the trigger condition for revisiting CMS investment when the roadmap adds editorial workflow, scheduling, versioning, approvals, or multichannel delivery.
• Fit map. Strong for marketing landing and campaign pages, legal/terms/privacy, about/team, docs-style static content, and localized brochure sites — pages with a fixed set of structured blocks rather than freeform authoring. Poor fit for anything where content owners need to invent new layouts without an engineer. A useful heuristic: if you can draw the page as a wireframe with named fields today, it fits; if the content team's first request is "let us drag things around," it doesn't.

When to Consider This Package

Consider nova-page when most of the following hold:

• The stack is fixed. Laravel with a Nova admin already in production or committed on the roadmap. Without Nova, this package is not a candidate — that requirement alone eliminates it, and the evaluation stops there.
• Content is structured and bounded. You can enumerate the page types today (standard page, legal, landing, team, pricing) and each has a field set a developer can define. The template-as-class model is the value proposition, and it only pays off when the shape of the content is knowable in advance.
• A small content team owns the copy. A handful of editors making modest-volume changes, where "add a field" being a deploy is acceptable rather than a bottleneck. If editors outnumber engineers by a wide margin or publish dozens of pages weekly, the deploy-per-field-set model starts to chafe.
• No editorial workflow requirement exists yet. Draft/published is a boolean — there are no approvals, scheduling, or versioning. If regulated content or a compliance sign-off process is on the near roadmap, that requirement is a disqualifier, not a nice-to-have, and process discipline around restricted publish permission is not a substitute for an audit trail.
• Structured pages are the whole need. You are not trying to manage a blog, product catalog, or multichannel content graph. This is for the brochureware tier of a site, not the content engine.
• You accept a small, forkable dependency. MIT license, small codebase, readable in an afternoon, zero downstream dependents. The honest risk is a single-maintainer project with no consumers absorbing a break — the mitigation is a deliberate audit and a fork contingency, not a vendor SLA.
• You can own the front end. The package stores and edits content; rendering, routing, caching, redirects for changed slugs, and rich-text sanitization remain your responsibility. Teams expecting a turnkey solution should budget for that work explicitly.

Look elsewhere — or treat this as a stopgap pending a real decision — when any of the following apply:

• Editorial workflow, scheduling, approvals, or versioned content are required now or within the planning horizon.
• Content owners need to compose new layouts without engineering involvement.
• The site is or is becoming a multichannel content source (app, email, syndication) rather than a set of rendered pages.
• You are not on Laravel/Nova, or you are on a Nova major this package does not support.
• Volume is high enough that per-page engineering work on templates becomes a recurring tax rather than an occasional one.
• Compliance, audit, or accessibility governance requires a formal vendor relationship with support commitments.

In those cases, run the full CMS evaluation. The value of nova-page is that it lets you defer that evaluation until you can justify it with measured evidence rather than forecast.

How to Pitch It (Stakeholders)

The one-line version. An open-source package that adds a page editor to the admin we already run, so marketing can update static pages themselves instead of filing tickets and waiting for a deploy — at no license cost and with no new vendor.

For executives. The problem it solves is a scheduling one, not a technology one. Every copy change currently consumes engineering capacity that should be going to the roadmap, and the marketing team is blocked on someone else's prioritization. Adopting this moves routine page maintenance to the people who own the content, and it does so without a procurement cycle, a new vendor relationship, a new login, or a new security review — because it lives inside the Nova admin we already operate and already audit. The alternative, a full CMS, is a multi-month evaluation and integration effort we cannot justify today against a requirement that is essentially "let marketing edit the About page." Expected outcome: fewer engineering tickets for content changes, faster marketing turnaround, and the content-platform decision preserved for when we have evidence rather than speculation.

For engineering. This is a small MIT-licensed Laravel/Nova package with one clear idea: one PHP class per page type, each owning its Nova field set, its SEO fields, and its Blade view. Content structure lives in code, so adding a field is a deploy rather than a schema migration. It stores pages as JSON payloads keyed by a template handle, with slug and publish flag — no per-field columns, no migration churn.

Be candid about what we're signing up for:

• We own the front end. Routing, rendering, caching, locale fallback, redirects when slugs change, and sanitizing rich text are ours, not the package's. That work is modest but it is real, and it belongs in the estimate.
• The migration story is manual. There are no content migrations; renaming a field orphans the old JSON key and requires a one-off backfill. Defensive defaults on every accessor are the discipline that keeps this cheap.
• Single maintainer, zero dependents, 239 stars. The codebase is small enough to read in an afternoon and MIT gives us a fork path. The ask is a deliberate audit before production plus a documented "vendor it into packages/" contingency, not a blanket risk acceptance.
• Verify the Nova constraint first. v0.4.0 adds Nova 5 compatibility via a community PR. Confirm in the composer require block whether Nova 4 is still supported or was dropped — that single line decides whether our Nova upgrade is optional or forced, and we should not discover it during a routine composer update.
• One known sharp edge. A /{slug} catch-all route placed incorrectly will swallow /login, /blog, and API 404s, and the failure mode is "every URL returns 200 with an empty page," which is an SEO incident rather than an exception. Planning for a last-positioned route with an explicit controller is part of the adoption, not a detail to be discovered later.

The recommendation. Adopt as a scoped, reversible bet: pin the version, audit the code, ship one template end-to-end as a vertical slice, and instrument page-change ticket volume before and after. Treat "we need editorial workflow, scheduling, or approvals" as the documented trigger to reopen the CMS decision — at which point we will be making that call with measured deflection data instead of a guess.