Systatic Laravel Package

Technical Evaluation

Architecture fit

• Systatic is a build-time CLI, not a runtime dependency. It compiles Markdown-with-frontmatter and Blade templates into a static HTML artifact. From a program perspective this is the decisive fact: it never touches a request path, so its failure domain is the CI build pipeline, not production traffic, and it cannot degrade availability of anything already serving users.
• It is Laravel-flavored without being Laravel-coupled: it leans on standalone Blade/Illuminate-style view and filesystem components plus Symfony Finder. That means a Laravel team gets immediate leverage on skills it already pays for — Blade templates, layouts, and components carry over — while a non-Blade team gets no advantage over Eleventy, Hugo, or Astro.
• The tool is opinionated about directory conventions and a single config file. Adopters adapt to its structure, not the reverse. That is acceptable for a greenfield docs or marketing microsite and a poor fit for retrofitting an existing site's information architecture.
• Competitive context is the program-level issue. Tighten's Jigsaw occupies the same niche (PHP, Blade, Markdown, static output) and is actively maintained. Systatic's only plausible differentiator is developer ergonomics, which does not justify carrying an unmaintained dependency. Any architectural case for Systatic has to be a specific reason not to use Jigsaw, and that argument is weak on the evidence available.

Integration feasibility

• Extremely low cost to test: a Composer require and a single build command, output published to any static host or CDN. A credible proof of concept is an afternoon, which means the decision cost of evaluating this is near zero even if the answer is "no."
• Two placement models: (a) an isolated site repository that depends only on the generator, or (b) embedded in the existing Laravel application. Model (a) is strongly preferred — see compatibility below; model (b) is where the package's dependency constraints collide with the framework's pinned versions.
• No asset pipeline story. CSS/JS bundling and image processing are the adopting team's problem. Budget for bringing Vite or equivalent, and treat that as part of the estimate rather than an afterthought.

Technical risk

• Adoption signal is effectively nil: 0 stars, 0 dependents, score 0. Whether that reflects genuine abandonment or a metadata artifact, the operational consequence is identical — no community, no third-party bug reports, no organic forks, no issue triage. From a program standpoint, "we would be the only users" is a governance fact, not just a quality signal.
• Bus factor 1, with no visible security disclosure path and no release cadence. There is no escalation route for a build-breaking bug and no vendor to hold accountable.
• PHP/Illuminate version ceiling is the acute, near-term risk. Packages of this vintage commonly pin constraints that no longer resolve against current PHP and current Illuminate releases. This must be validated before any commitment, because failure here collapses the entire business case.
• Implicit lock-in is to conventions, not content. Output is plain HTML and source is plain Markdown plus Blade. Content survives any future migration; only templates need rewriting. That materially lowers the downside of a timeboxed trial and is the core argument for permitting one.
• No evidence of incremental builds or parallel rendering. Assume full, single-threaded rebuilds, and assume build time scales linearly with page count.

Key questions

1. Does it install and build cleanly on our current PHP (8.2/8.3) and Composer 2.x, today, from a clean lockfile?
2. Who owns the fork when it breaks, and is the ongoing cost lower than simply adopting Jigsaw (zero licence cost, active maintenance)?
3. What is the real page count and build-time ceiling for our intended content set — measured, not estimated?
4. Can it be isolated in its own repository, or is there a hard requirement to coexist with the existing Laravel composer.json?
5. Which required capabilities (pagination, taxonomies, search index, RSS/sitemap, i18n) are built in versus hand-rolled in Blade — and who funds the hand-rolling?
6. What are the written exit criteria and the rollback path if the spike fails or the fork owner leaves?

Integration Approach

Stack fit

• Strong only where PHP is already a first-class runtime and Blade is familiar. The value proposition is stack consolidation — one language, one templating engine, one design system — not technical superiority over mature JavaScript generators.
• Poor where the front-end team already owns a Node pipeline (Vite/Astro/Eleventy). Introducing a second toolchain and a second language boundary for static pages adds hiring and onboarding cost for no delivery gain.
• Neutral on hosting, which is where the operational argument is strongest: static output deploys anywhere, eliminating a PHP runtime, a database, and their patching obligations from the production surface.

Migration path

• Inbound is cheap and largely mechanical. Markdown and YAML frontmatter carry over from Jekyll/Hugo/Eleventy almost untouched; only template syntax is rewritten to Blade. Migrating off a Laravel-rendered marketing site or a CMS is a content-extraction exercise, not a re-engineering one.
• Outbound is equally cheap, which is precisely why tolerating the maintenance risk is defensible. Blade templates translate to Jigsaw with minimal edits; Markdown needs no changes at all. Frame the initiative internally as a low-regret, reversible experiment — that framing is what makes it approvable.
• The migration cost is not the code; it is the editorial and review process change from "edit in a CMS" to "open a pull request." That is a change-management line item affecting content owners, not engineers.

Compatibility

• Do not install this into the same composer.json as the Laravel application. Its Illuminate constraints will fight the framework's pinned versions; the likely outcomes are resolution failure or a silent downgrade of shared packages affecting production. Isolate it as a standalone build project with its own lockfile.
• Pin the CI PHP version to exactly match local development, and commit composer.lock. With no upstream releases, an unpinned lockfile is the single most likely route to a broken build appearing without any code change.
• Identify the Markdown/CommonMark dependency it pulls in. That library is the most probable source of transitive updates and of any differences in rendered output between environments.

Sequencing

1. Install spike (1 day): clean directory, target PHP version, build three representative pages. If Composer resolution fails, stop here and report out — the ROI case is dead and no further time should be spent.
2. Feature-gap audit (2–3 days): enumerate what the actual site requires — pagination, tags, sitemap, RSS, redirects, search index, i18n — and confirm each is either built in or cheaply hand-rolled. This audit is also the input to the exit-criteria decision.
3. Asset pipeline decision: wire CSS/JS/image handling around the generator before templates proliferate, so the pipeline is not retrofitted later.
4. CI build plus preview environment: build on every PR and publish to an ephemeral preview URL, so content reviewers and stakeholders can see real output rather than diffs.
5. Cutover with rollback: keep the prior site buildable for one release cycle. Static output makes rollback trivial; plan it anyway.
6. Fork ownership handover: name the owner, write the runbook, and schedule the dependency-review cadence before the spike closes — not after the first outage.

Operational Impact

Maintenance

• Treat it as fork-and-own from day one. Budget a small but recurring allocation for dependency drift and PHP upgrades, and record it as a real line item so the total cost of ownership is compared honestly against Jigsaw (which is free, active, and removes this line entirely).
• Partial mitigation exists but should not be oversold: the bulk of the code actually exercised — Blade, the Illuminate view/filesystem components, Symfony Finder — is maintained by others and receives security patches independently. The unmaintained surface is the glue layer, which is also the surface most likely to break on a version bump.
• Add a scheduled build and a composer outdated check to catch silent breakage before a content author discovers it in production.

Support

• There is no maintainer support, no issue triage, and no documentation beyond a README. Internal ownership, a named maintainer, and a short runbook are mandatory preconditions, not nice-to-haves. This is the single most important thing to secure before approval.
• Onboarding documentation will not exist unless the adopting team writes it in the first sprint. Budget that time explicitly — there is no community to ask questions of, so undocumented behaviour stays undiscovered until it causes an incident.

Scaling

• Serving scales essentially perfectly: static files on a CDN, no origin, no cold starts, negligible marginal cost, and a dramatically smaller security review surface than another database-backed application. This is the strongest part of the business case and the easiest part to justify to stakeholders.
• Building is the real ceiling. Expect single-threaded, full-site rebuilds. Content sets in the low thousands of pages will turn CI into the editorial bottleneck and lengthen the publish loop. Measure this during the spike against a synthetically padded content set rather than discovering it post-launch.
• If build time becomes the binding constraint, that is the trigger to migrate — and portable Markdown makes that migration cheap, which is exactly why the risk is tolerable.

Failure modes

• Dependency resolution failure on a PHP or Illuminate bump. Most probable failure, and it lands squarely on the fork owner with no upstream to escalate to.
• Build-time-only validation. Broken internal links, missing templates, and malformed frontmatter surface as silently wrong output rather than errors. Add a link checker and HTML validation to CI; the generator will not provide them.
• Partial or empty deploy. A failed build that publishes a truncated output directory takes the site down. Publish atomically, or fail the pipeline closed.
• Local/CI environment drift producing output that differs between a developer machine and production — particularly around PHP version and Markdown rendering.
• Content-authoring friction. Non-engineers editing YAML frontmatter will create errors the tooling does not catch. Add schema validation on frontmatter before widening authoring beyond engineers.

Ramp-up

• Low for anyone with Blade and Markdown experience: a developer is productive in one to two days; a content author in under an hour, provided templates and frontmatter schemas already exist.
• The hidden ramp-up cost is not learning the tool — it is discovering and documenting the undocumented behaviour, which must be reverse-engineered from source and then written down internally. Budget this explicitly in the spike, because there is no community, no maintainer, and no third-party tutorial to fall back on.