Jigsaw Laravel Package

Product Decisions This Supports

• Build vs. buy for content surfaces. Jigsaw answers "should we stand up a CMS/server just to publish docs, a marketing site, or a landing page?" A Blade-to-static-HTML pipeline means no database, no runtime, no patching cadence — just generated files on a CDN. That's a meaningful reduction in total cost of ownership for any site that is read-only in nature.
• Feature/roadmap scoping. It gives the team a fast, low-risk way to ship destination pages for launches, pricing, changelogs, docs, and event microsites without committing engineering time to a full app or blocking on a marketing CMS contract.
• Team-capability fit. The decisive input is language alignment: if the org is Laravel/PHP-centric, Jigsaw lets existing engineers contribute to marketing and docs sites using Blade, layouts, and components they already know — no new templating dialect (Go templates, Liquid, Nunjucks) to hire or train for.
• Reversibility as a decision criterion. Content lives in Markdown plus Blade views and compiles to plain HTML. That makes this a low-lock-in bet: the output is portable to any static host, and the source is legible to future maintainers. Good candidate for "decide fast, revisit later."
• Documentation as a product surface. Collections, Markdown, and pagination cover docs, guides, and blog-style content well — supporting decisions like "launch a public developer docs site this quarter" without a platform team.
• Deployment topology. Choosing static generation pushes the hosting decision toward CDN/object storage (Netlify, Vercel, S3, GitHub Pages) — cheaper, faster globally, and a shorter security review than a hosted CMS or a small Laravel deployment.

Caveat to weigh: the package metadata shows a low dependent count. That's expected and not a red flag — Jigsaw is a dev-time CLI/scaffolding tool, not a runtime library, so it will never appear as a transitive dependency. Judge it on stars (~2.2k), maintenance recency, and the fact that it's backed by a known Laravel consultancy, not on dependent counts.

When to Consider This Package

Adopt when most of these are true:

• The deliverable is static or near-static: docs, marketing site, blog, handbook, landing/microsite, conference site, prototype.
• The team already writes PHP/Blade or has Laravel engineers who will own the site long-term.
• You want near-zero infrastructure: no server, no DB, no admin panel to secure or maintain.
• Content volume is moderate and editorially controlled — a handful of contributors committing Markdown to Git is acceptable.
• You need speed to first deploy over deep extensibility, and you're comfortable wiring assets yourself (Vite/Mix-style build step is on you).
• Procurement/security wants a small, auditable surface: MIT license, no vendor contract, no PII at rest.

Look elsewhere when:

• Content is dynamic or personalized — auth, gated content, search-as-a-service, forms with server-side handling, A/B tests, or CMS workflows for non-technical editors at scale. Jigsaw has no editorial UI or content API.
• The team is JavaScript-first. Astro, Next.js, Eleventy, or Docusaurus will have better hiring, ecosystem, and component-model fit. Choosing a PHP SSG for a JS org is a maintenance tax with no payoff.
• You need batteries-included docs features — versioned docs, built-in search, i18n routing, dark-mode/theme ecosystems. Docusaurus or MkDocs Material get there without custom glue.
• Ecosystem depth matters. Hugo/Jekyll have far larger theme and plugin communities; expect to write or maintain your own helpers and integrations here.
• You need a vendor SLA or commercial support contract. This is community-maintained with consultancy heritage, not a supported product.

How to Pitch It (Stakeholders)

To executives: Jigsaw is a small, MIT-licensed tool that turns Laravel's Blade templates into plain static HTML. For us that means content sites — docs, marketing pages, launch microsites — ship with no server, no database, and no hosting bill worth discussing, on a CDN that's fast globally and has almost no attack surface to review. It's backed by Tighten, a well-known Laravel consultancy, it's actively released, and because everything compiles to portable HTML plus Markdown, the decision is cheap to reverse if our needs change. The strategic value isn't the tool itself — it's that we stop spending engineering cycles on infrastructure for pages that don't need any.

To engineering: This is Blade, layouts, and Markdown with a build step — nothing new to learn if you've touched Laravel, and no runtime to operate. You get collections, pagination, and custom helpers; you own the asset pipeline and any search/i18n you need. The trade-off is explicit: we're trading ecosystem breadth and built-in docs features for zero operational burden and full control of the output. If we later need auth, personalization, or a real editorial workflow, we treat that as a migration trigger, not a surprise — and the Markdown content comes with us.

Recommended framing: approve as a bounded, reversible experiment — one docs site or one marketing microsite, with a written trigger for when we'd outgrow it.