Jigsaw Blog Template Laravel Package

Product Decisions This Supports

Feature scope for a content surface — what's in and what's out. tightenco/jigsaw-blog-template is a clone-and-own starter for Jigsaw, Tighten's Blade + Markdown static site generator. It ships the pieces a blog roadmap actually needs on day one: post listings and article pages, Markdown with front-matter metadata, pagination, responsive Tailwind styling, and a simple structure for pages and site settings. It does not ship comments, search, authentication, personalization, multi-author roles, or scheduled publishing. Treat those as separate line items with their own budgets — they are third-party services or a different platform, not template features to "turn on later."

Build vs. buy for the content site. The real decision set is this template vs. a managed CMS (Ghost, Contentful, Sanity) vs. a JS-framework site (Next.js, Astro). This option collapses "build" to near zero conditionally: only if the team already writes Laravel/Blade. If the front-end org is standardized on React/Vue, the build cost doesn't vanish — it hides in a PHP build step nobody wants to own. Surface that trade-off in the decision doc rather than discovering it after the scaffold is in production.

Hosting, cost, and ops roadmap. Output is static files deployable to any CDN or object store — Netlify, Cloudflare Pages, S3 + CloudFront, GitHub Pages. Present that as a product decision, not just infrastructure: no database, no runtime to patch, no server-side attack surface, negligible marginal cost per page view, and content-site uptime decoupled from application uptime.

Toolchain standardization. v1.4.1 moves the template to Vite and Tailwind 4. That lets the content site align with the org's modern asset pipeline instead of maintaining a parallel one. The inverse is a real constraint: if the design system is pinned to Tailwind 3, adopting v1.4.1 means diverging from the design system or migrating it — a cross-team dependency that belongs in the decision record, not in a sprint.

The authoring model is a product constraint, not a detail. Publishing is Git-based: authors write Markdown and open pull requests. That decides who can publish. It fits developer-authored and engineering-adjacent content — changelogs, docs, engineering blog. It fails for self-serve marketing. Make this call explicitly and early, because reversing it later is a platform migration, not a settings change.

Adoption posture: vendored snapshot, not tracked dependency. The template's files become your codebase. There is no composer require, no semver contract; 1.4.1 is a snapshot label, not a compatibility promise. So the PM decision is not "upgrade or not" but "vendor once and treat upstream as reference documentation, reviewed on a cadence" — quarterly is a reasonable default. Budget roughly a day per meaningful upstream change, and expect "skip" to be the answer more often than not.

Use cases to route to this option: company blog, changelog, docs and guides, landing pages, conference or product microsites, internal knowledge bases published as static sites — anything read-mostly, content-led, and CDN-servable.

When to Consider This Package

Consider it when:

• The team already writes Laravel, Blade, and PHP — same-day ramp, no new framework to learn or staff.
• Content is developer-authored or lightly edited Markdown, and the people publishing are comfortable with Git and pull requests.
• You want static output for speed, SEO, cheap CDN hosting, and minimal operational burden.
• The site is small-to-medium (blog, docs, changelog) where a full CMS is overkill and the content model is simple.
• The target is greenfield. A fresh scaffold from v1.4.1 sidesteps migration entirely — this is the cheapest path and the one to prefer.
• You're willing to own the build pipeline — Composer, npm/Vite, CI deploys, and the template's Vite asset-resolution helper — as first-party code.

Look elsewhere when:

• Non-technical marketers need WYSIWYG editing, scheduled publishing, roles, or approval workflows. Evaluate a headless CMS, Ghost, or WordPress.
• You need request-time capability: comments, search, auth, personalization, commerce, or forms with server logic. Scope those as separate services or pick a different stack up front — bolting them onto a static generator later is the expensive path.
• The front-end team is standardized on React/Vue/Next/Astro and would resent running a PHP build step.
• You need enterprise content governance, localization workflows, or heavy editorial scale.
• You require vendor support contracts or SLAs. Jigsaw and this template are community open source on best-effort maintenance — one PR and one first-time contributor on the current release is the maintenance signal, and it is thin.
• You already forked v1.4.0 or earlier and the delta is large. v1.4.1 is a patch number on a toolchain replacement: Laravel Mix → Vite, Tailwind 3 → 4. Treat it as a breaking migration with a time-boxed spike, not a bump. If the spike overruns, staying on v1.4.0 is a legitimate outcome — nothing here is a security fix.
• Your browser-support commitments or design system are pinned such that Tailwind 4's moved browser floor is unacceptable. Check analytics before committing.

Name this trap explicitly in the decision doc: the patch number is a misleading risk signal. Anyone reading 1.4.1 as low-risk will under-resource the port.

How to Pitch It (Stakeholders)

For executives. We can launch a fast, low-cost blog and content site from a current open-source Laravel template instead of buying or building a CMS. No database, no server to patch, hosting on a CDN for pennies, and pages fast enough to help SEO and conversion. The latest release modernizes the front-end build (Vite, Tailwind 4), which signals the project is maintained and lowers adoption risk. The trade-off to accept knowingly: publishing is Git-based, so this fits teams with engineering support, not a self-serve marketing CMS. If marketing needs to publish without engineering involvement, this is the wrong tool — and we should say so now rather than discover it next quarter.

For engineering. jigsaw-blog-template v1.4.1 is a Jigsaw starter — Blade plus Markdown compiled to static HTML — now on Vite and Tailwind 4. Adopt it as the baseline where we control the repo and CI, for greenfield content sites. Three things to internalize:

1. It is a template, not a dependency. No composer require. Cloning pins us to a snapshot; upstream drift is permanent and one-directional. The sustainable posture is to vendor v1.4.1 once, treat upstream as reference documentation, and review releases quarterly. Assign an internal owner for the Vite asset-resolution helper — Jigsaw doesn't ship one, so it's template-owned code we now maintain, and it's the likeliest source of a silent break.
2. v1.4.1 is a toolchain migration wearing a patch number. webpack.mix.js disappears, npm scripts change shape, hashed assets move from mix-manifest.json to .vite/manifest.json, and Tailwind 4's CSS-first config (@theme) largely replaces tailwind.config.js. Custom theme tokens, plugins, and safelists will not port by copy-paste. Verify the Node floor (Vite + Tailwind 4 want 20+) in CI and in the deploy image before the port.
3. Migration sequence if we have an existing fork: pin v1.4.1 on a throwaway branch and diff against v1.4.0 → classify changes as build tooling, layouts/partials, content scaffolding (ignore), and config → port tooling wholesale, layouts selectively, leave source/ alone → re-add local customizations on top → smoke-check. Keep the spike discardable and time-boxed.

Failure modes to instrument, because none of them throw an error: a broken manifest path yields 200 OK pages rendered completely unstyled; renamed Tailwind 4 utilities silently produce missing styles. Neither is caught by unit tests. Add a post-deploy smoke check asserting a known hashed CSS asset resolves, plus visual regression on a representative page set, and pin Node in .nvmrc and the CI image together.

If the roadmap includes comments, search, auth, or editor-facing authoring, scope those as separate services now — or choose a different platform up front. Bolting them onto a static generator later is the expensive path, and it is the decision most likely to be regretted.