Ux Blocks Marketing Laravel Package

Product Decisions This Supports

• Build vs. buy for marketing surfaces. This package is a "buy" answer for the lowest-value, highest-frequency UI work we do: hero sections, CTAs, pricing tables, testimonials, feature grids. If it works, it converts design/dev hours into configuration hours on every campaign page after the first.
• Landing page and campaign velocity. Marketing requests a page for a launch, a webinar, a paid-ad destination, or a partner co-marketing push. The blocks give us a standard vocabulary to ship those in days, not sprints, and without pulling a product engineer off the roadmap.
• Roadmap sequencing: do we invest in an in-house page builder or not? A credible set of composable blocks de-risks deferring the expensive internal CMS/page-builder investment. It buys us 2–3 quarters of "good enough" while we validate whether marketing self-serve is actually a bottleneck worth solving properly.
• Experimentation infrastructure. Pre-built, parameterized sections make it cheap to stand up A/B variants (hero copy, CTA placement, pricing layout). That supports conversion-rate experiments and pricing-packaging tests that currently stall because each variant needs bespoke markup.
• Self-serve marketing enablement. If blocks are assembled from JSON/DB records (the composition pattern the package encourages), non-engineers can reorder and re-populate pages without deploys. That's a product capability decision: is marketing autonomy worth a small platform investment?
• Time-to-market for new market/segment entry. Launching a localized or segment-specific landing page becomes a content exercise, which affects go-to-market sequencing decisions.
• Where we should not spend roadmap. Anything this package already covers is a candidate to cut from the internal backlog — that's a concrete capacity decision.

When to Consider This Package

Adopt when most of these hold:

• Stack fit: We're on Laravel 10/11+ with Blade (Twig compatibility is claimed but unproven here), and we already have a Vite asset pipeline we can wire it into.
• Scope is bounded: Marketing/landing pages only, deliberately isolated on their own layout. It is not an app UI kit and should not leak into admin or product surfaces.
• Small team, thin design bandwidth: We don't have a dedicated design system team, or the existing system has no marketing section library. The blocks are the fastest path to consistent-looking pages.
• Volume justifies it: We expect roughly 5+ landing/campaign pages per quarter. At one or two pages a year, hand-writing the markup is cheaper than the integration and upgrade overhead.
• Risk tolerance is calibrated: We can pin an exact version, snapshot rendered output, and accept that a 0.1.x package may break on a minor bump. Funnels must not be on the critical path without that guardrail.
• We'll test it: The team will spend the half-day to render each block in isolation with representative data before committing. This is the single best predictor of "works in prod."

Look elsewhere (or build in-house) when:

• Brand fidelity is non-negotiable. Consumer brands with strict design systems, custom motion, or a11y/compliance requirements will fight packaged markup. Forking defeats the purpose.
• CMS/authoring is the real requirement. If the actual need is a multi-tenant page builder with roles, workflows, versioning, and scheduling, blocks are a rendering layer, not a solution.
• Internationalization, accessibility, or SEO are hard gates. Nothing here indicates tested RTL, WCAG conformance, or structured-data/schema output. Assume you own all of that.
• Performance budget is tight. Marketing pages are the most SEO- and Core-Web-Vitals-sensitive surface we own. Dependency-free markup helps, but CSS purge quirks (Tailwind content globs missing vendor views) are a documented failure mode — and unstyled-in-production only.
• Maintenance risk is unacceptable. Zero stars, one maintainer, no visible adoption, pre-1.0 API, release notes that just link to a changelog. If the vendor disappears, we own the code. That's survivable for marketing pages; it is not for anything customer-critical.
• Non-Laravel or mixed-stack frontends. The integration story is Blade-centric; a Next.js or Nuxt marketing site gets much less value.
• We already own a design system with marketing components. Then this is redundant, and the override/publish machinery is pure overhead.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a low-cost, low-commitment bet on shipping marketing and campaign pages faster. It's a Laravel package of pre-built landing-page sections — hero, CTA, pricing, testimonials, features — that our engineers can compose instead of hand-building each page. The upside is time-to-market: weeks of design and front-end work per campaign becomes days of configuration, and it defers a much larger internal page-builder investment until we've proven the demand. The risk is maturity: it's an early-stage (0.1.x), single-maintainer, zero-adoption package, so we should pilot it on non-critical marketing pages with a pinned version and a documented fallback to hand-rolled Blade. Recommendation: time-boxed pilot on the next 2–3 campaign pages, measure hours saved per page, and revisit at 1.0 or after three cycles.

For engineering (what we're asking for):

• Treat it as a rendering layer, not a platform. Blocks are self-contained Blade components composed into pages; page structure lives in our data (blocks JSON with {type, data}), resolved by our loop. We keep the data model and the routing; they only supply markup.
• Isolate it. A dedicated marketing layout, the package's asset stack included once, explicit ux-blocks-marketing:: namespace everywhere. No block styles in app or admin.
• Pin and guard. "^0.1.2" or exact-pin, changelog diffed on every bump, published views diffed against vendor after each update, and a feature test per block asserting key strings. Cheap insurance.
• Extend, never fork. Override individual block views or register custom components under the same key. A vendor fork dies on the first patch.
• Prove it before we build on it. Spike: install, publish, render one hero block in an existing view, run a production build (npm run build) to catch Tailwind purging and asset-include problems. Half a day. If that spike is painful, we stop there and the cost is trivial.
• Define the exit. If the package stalls or the API churns, we fall back to our own components — the {type, data} contract means the page data survives; only the templates get rewritten. Keeping that seam clean is a prerequisite, not a nice-to-have.

Bottom line: worth a scoped pilot on marketing pages only. Do not put revenue-critical funnels on it until it hits 1.0 or we've run three campaign cycles without a breaking change.