Jigsaw Docs Template Laravel Package

Product Decisions This Supports

• Build vs. buy on documentation. Gives product a concrete "build" line item to put beside GitBook, ReadMe, Confluence, and JS-native generators. The comparison becomes engineering setup hours + indefinite fork ownership versus per-seat licensing + lock-in — a decision that can be closed in a week instead of a quarter.
• Sequencing a docs roadmap. Turns "we need docs" from a multi-sprint project into a two-to-three-day v1. That enables a staged plan: ship a credible site → instrument page traffic and drop-off → fund search, versioning, or a paid platform only where the evidence points.
• Activation and time-to-first-success. For a developer-facing Laravel/PHP product, quickstart quality is a direct lever on trial conversion and support volume. This lets you test whether better docs actually move those numbers before committing headcount to a docs program.
• Scope negotiation. It makes the v1 boundary tangible and defensible: no versioned docs, no built-in search, no i18n, no editorial workflow. Product can point at a real artifact rather than argue over what "docs" means.
• Stack standardization as a product constraint. Choosing Jigsaw keeps authoring in Markdown + Blade and reinforces existing PHP competency rather than importing a React docs toolchain. That decides where the team's permanent maintenance surface lives — a product-org call, not purely technical.
• Internal knowledge surfaces. Credible for runbooks, architecture notes, onboarding, and platform docs — an off-ramp from an unnavigable wiki with no procurement, no seats, no vendor review.
• A price floor for future docs bets. Even if rejected, it calibrates what "minimal viable docs" costs in days, sharpening any later business case for Docusaurus, Astro Starlight, VitePress, or a paid platform.

When to Consider This Package

Consider it when:

• The team is Laravel/PHP-fluent and already has PHP in CI — Blade partials, config.php collections, and the asset pipeline are sunk-cost familiarity.
• Docs scope is genuinely modest: a quickstart, a handful of guides, tens of pages, one version, one language.
• You want static HTML deployable to GitHub Pages, S3/CloudFront, Netlify, or Cloudflare Pages with no server, database, or auth surface to own.
• Branding and information architecture must be fully owned, with no per-seat pricing and no content trapped in a vendor.
• You're running a deliberate pilot and accept that the artifact becomes yours to maintain from day one.

Look elsewhere when:

• You need versioned docs, built-in full-text search, i18n, or generated API references. Docusaurus, VitePress, Nextra, Astro Starlight, and MkDocs Material are materially ahead, and retrofitting those capabilities erases the cost advantage.
• Your engineering stack is Node/Python/Go-only. Note the template ships a Vite-based asset pipeline, so adoption means introducing PHP and Node — plus Tailwind — purely to render Markdown. Poor trade against generators the team already owns.
• You need vendor support, SSO, hosted analytics, editorial review, or governance at scale. Buy the platform.
• Documentation is, or is about to become, a customer-critical revenue surface requiring a support commitment.
• You need incremental builds or expect to scale past roughly one to two thousand pages; Jigsaw's full rebuild becomes the bottleneck.

Honest calibration. 50 stars and 0 dependents is normal for a template — teams fork these, they don't depend on them. More instructive is the release history: recent versions are dependabot bumps only, meaning upstream maintenance is passive hygiene, not active feature development. Treat the ~13 opportunity score as directional: this is a time-saver worth roughly a week of setup, not a platform bet, and any date or version metadata in the feed should be verified rather than trusted.

How to Pitch It (Stakeholders)

Executive summary. This isn't a purchase — it's a free, MIT-licensed starting point for a documentation site built on Jigsaw, Tighten's PHP static site generator. The product case is speed and cost: our existing PHP/Blade team can ship a branded, fast docs site in days instead of weeks, with no subscription, no procurement, and no new authoring model. Output is static HTML, so hosting is cheap, latency is low, and there is no runtime security surface to own.

For engineering. It fits a stack we already operate: Blade components, config.php collections, Markdown with front matter, Tailwind for styling. Content stays portable in both directions, keeping switching cost low. Be precise about the build, though — the template carries a Vite asset pipeline, so the build needs PHP 8.x, Composer, and Node. Pin and containerize that environment rather than installing "latest," and add per-PR preview deploys to neutralize the main operational risk. Expect theme and IA customization in Blade to be the real effort, not the Markdown port.

For finance and operations. Zero license cost, zero vendor lock-in, negligible hosting spend, no procurement cycle, and no per-seat line item as the team grows.

Risk, stated plainly. The ecosystem is small and the template is passively maintained; the moment we adopt it, it becomes ours to own. Three specific exposures: theme changes require Blade fluency, which is a bus-factor risk worth documenting or deliberately freezing; search, versioning, and localization are out of scope — the three features most likely to force a re-evaluation; and migration effort concentrates in navigation definitions, any custom shortcodes, and redirect parity for changed URLs, which should be a launch gate rather than a follow-up ticket. None of this is severe because the output is static and the blast radius is confined to the build chain.

Recommendation. Approve as a timeboxed, low-cost pilot for internal documentation or a first public docs site. Success criteria: published in under a week, one real docs set ported (20–50 pages, including a code-heavy page with large tables and nested nav), measured build time and authoring friction versus the status quo, redirect and accessibility parity verified, and a named fork owner with a written upgrade policy — even if that policy is "we will not sync upstream." Set an explicit review checkpoint, triggered by any of versioned docs, search, localization, or docs becoming a strategic customer surface, at which point we re-run this comparison against a modern generator or a paid platform.