Layouts Standard Laravel Package

Product Decisions This Supports

• Build vs. buy for page composition. Netgen Layouts is a layout/page-management layer: editors assemble pages from reusable blocks instead of requesting bespoke templates. This package is the "standard library" of those blocks and layouts, so the real decision it informs is whether to adopt a page-builder layer at all versus hand-building landing-page templates.
• Time-to-first-page estimates. Because it ships a pre-built set of commonly used blocks, it shifts the estimate from "design and build a block library" to "install, theme, and extend." Useful when scoping an MVP content site or a marketing site refresh.
• Roadmap sequencing for editor-facing features. If the roadmap includes "marketing can publish landing pages without engineering," this package defines the baseline capability set you get on day one versus what you must build (custom blocks, integrations, preview workflows).
• Feature scoping and reuse. A standard block catalog is a forcing function for consistency: it caps the number of one-off templates and makes "which block types do we actually support?" an explicit product decision rather than an emergent one.
• Applicability check against your stack. The package is built for the Netgen Layouts core bundle in a Symfony/Ibazza-style ecosystem (it is not a Laravel-native package). It's most useful as a signal for whether the underlying Layouts platform is a credible option — not as an independently adoptable component.

When to Consider This Package

Consider it when:

• You are already committed to (or seriously evaluating) netgen/layouts-core and want the fastest path to a working set of blocks and page layouts.
• You need a forkable, MIT-licensed baseline. The value here is the reference implementations and configuration, not a supported product — plan to own and extend it.
• Your team is comfortable in Symfony and Twig, and you accept that custom blocks, styling, and admin UX will be your work.
• You want to derisk a page-builder decision cheaply: install it in a spike, have an editor assemble a real page, and measure the gap between standard blocks and your actual content model.

Look elsewhere when:

• You are on Laravel. There is no native integration; you'd be pulling in the core bundle and its Symfony dependencies, which is a poor fit for a Laravel codebase.
• You need vendor support, SLAs, or a large plugin ecosystem. With ~22 stars and effectively no downstream dependents, community support is minimal and bus-factor risk is real.
• You want a headless or JavaScript-first page builder (React/Vue editors, API-driven delivery), or a SaaS visual editor with a mature component library.
• Your requirement is structured, model-driven content rather than free-form page assembly — a CMS with well-designed content types may be the better product answer.

Treat this as a starter kit and reference implementation, not a dependency you adopt and forget.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed add-on to the Netgen Layouts platform that gives editors a ready-made library of page blocks so marketing can assemble campaign and landing pages without engineering tickets. The commercial upside is cycle time, not license cost — it's free. The risk is ecosystem size: the project is niche, so we should treat it as a foundation we own and extend rather than a supported product, and validate it in a short spike before letting it into the roadmap.

For engineering: It's essentially configuration and templates defining standard blocks and layouts on top of netgen/layouts-core — a thin, fork-friendly surface with no lock-in beyond the platform choice. Expect to write custom blocks, theming, and editor-facing polish; budget for that rather than assuming the standard set is sufficient. Note the framework fit: this is a Symfony/Twig ecosystem play, not a Laravel one, so it only makes sense if the underlying platform is already a candidate.

Recommendation: Evaluate as a time-boxed spike against the real content model, with the explicit question "how far does the standard block set get us before we write our own?" If the answer is most of the way, it's cheap acceleration; if it's a third of the way, the platform decision — not this package — is the thing to debate.