Gustamic Laravel Package

Technical Evaluation

Architecture fit

• v1.1.0 confirms this is a Statamic starter kit built on Laravel, not a conventional Composer library. Fit is therefore conditional: strong if the target stack is Statamic 6.x on Laravel 13, weak-to-none if the team runs plain Laravel with Blade/Livewire/Inertia and no CMS layer.
• The release improves two architectural seams that matter to a TPM: content-model coupling (menu links now resolve the menu page entry instead of a hardcoded /menu slug) and configuration as source of truth (JSON-LD sameAs and analytics derived from Restaurant Details rather than template literals). Both reduce the "edit the code to change the site" class of work.
• Script-safe encoding of JSON-LD and analytics values is a defense-in-depth hardening of the Control Panel → rendered-output path. CP access is already privileged, so this is not a critical CVE-class fix, but it removes a trivially exploitable stored-injection vector and signals the maintainer is doing security-minded review.
• Licensing is now explicit (MIT) plus a .gitignore, which clears the usual legal/procurement gate that blocks evaluation of unlicensed repos.

Integration feasibility

• Low technical friction for a greenfield Statamic build: scaffold, seed sample content, point at Restaurant Details, swap placeholder assets. Demo link materially shortens the "is this worth a spike?" decision.
• Non-greenfield is the harder case. Starter kits are typically forked, not upgraded via Composer, so v1.1.0's fixes (menu-link resolution, script-safe encoding, default sample-content install, font/preload cleanup) will not flow automatically to sites scaffolded from v1.0.0. Expect a manual diff-and-port task per existing site.

Technical risk

• Compatibility risk (medium): "verified on Statamic 6.35 / Laravel 13" is a single tested pair. Laravel 13 is recent; if we are on Laravel 11/12 or Statamic 5.x, verification does not transfer and we own the upgrade risk.
• Seed-behavior risk (medium): "sample content now installs by default on non-interactive installs" is a reproducibility win for CI but a production-pollution hazard if any deploy pipeline invokes the installer non-interactively. Needs an environment guard before it reaches an automated pipeline.
• Drift risk (medium): fork-based distribution means our copy diverges from upstream; without a documented diff/port ritual, security fixes like the script-safe encoding will be missed on future upgrades.
• Placeholder-asset risk (low): Unsplash photos and a Logoipsum logo ship with a demo; brand/legal review must confirm nothing placeholder reaches production.
• Residual unknowns: no CI/test-suite evidence, no stated accessibility or Core Web Vitals baseline, no supported-version matrix.

Key questions

1. Are we committing to Statamic as a platform, or evaluating this as a reference implementation for a plain Laravel build?
2. Which Laravel/Statamic/PHP versions are we actually on, and is Laravel 13 in scope this cycle?
3. Is sample-content seeding gated by environment (local/CI only), and which pipeline steps invoke a non-interactive install?
4. What is the upgrade contract for forked kits — is there an upstream-diff process we can adopt?
5. Is there a test suite/CI we can pin to, and who owns accessibility and performance acceptance?
6. Support expectations: MIT with community-only support, or is a commercial Statamic relationship in place?

Integration Approach

Stack fit

• Target: Laravel + Statamic 6.35+ on PHP supported by that pair. This kit assumes Statamic's flat-file content model, Antlers/Blade templates, and a Control Panel editing workflow.
• If the stack is plain Laravel without a CMS, treat this as a design and content-model reference (Restaurant Details fieldset, menu page entry pattern, JSON-LD generation) rather than a dependency.

Migration path

• Greenfield: scaffold in a non-production environment, seed sample content, replace placeholder imagery/logo, map Restaurant Details fields to real data, rename the menu page slug to the client's preferred URL and confirm nav follows it, then promote.
• Existing v1.0.0-derived sites: do not attempt a package upgrade. Produce a three-file diff and port the v1.1.0 changes in this order: (1) script-safe encoding of JSON-LD/analytics, (2) menu-link entry resolution, (3) font/preload removal, (4) seed default (apply only if we want it), (5) cosmetic footer lines.
• Non-Statamic targets: lift the JSON-LD and analytics emission patterns into our own Blade components; skip the rest.

Compatibility

• Pin exact versions in composer.json; do not let the "verified on" pair float. Add a smoke test that renders the menu page, the footer nav, and the JSON-LD block.
• Verify the menu-page entry exists and the blueprint exposes the fields the new link resolution depends on — the fix trades a hardcoded path for a content dependency.
• Confirm the social-profile fields in Restaurant Details tolerate empty/partial input so sameAs degrades to omitted rather than emitting an empty array.
• Validate output in a structured-data linter and confirm </</script> payloads in CP fields render escaped.

Sequencing

1. License/procurement sign-off (unblocked by MIT).
2. Demo review and stakeholder go/no-go on the design direction.
3. Spike: scaffold on the target version pair; time-box to a day.
4. Content-model mapping workshop (Restaurant Details, menu structure, social profiles).
5. Security/perf verification pass on the spike (structured data, escaping, font requests, LCP).
6. Decide fork-vs-reference; document the upstream-diff ritual if forking.
7. Port fixes to any existing v1.0.0-derived installs before further work.
8. Asset replacement and brand review, then staging sign-off.

Operational Impact

Maintenance

• Low ongoing code maintenance: MIT, single-vendor stewardship, small surface area. The real cost is fork drift — budget a recurring (e.g. quarterly) upstream review to pull security and correctness fixes.
• Content maintenance is delegated to the CP by design (Restaurant Details, page entries), which reduces developer involvement in routine copy changes — a net reduction in ticket volume if editors are trained.

Support

• No SLA, no vendor support channel implied. Plan on community/issues-based support and internal ownership of anything we customize.
• If the restaurant site is business-critical (ordering, reservations, hours), the absence of a support contract is a material gap to raise with stakeholders.

Scaling

• Statamic's static/Blade caching makes this comfortable for restaurant-scale traffic; JSON-LD and analytics generation are render-time and cacheable.
• Main scaling watch item is cache invalidation on CP edits — confirm the caching strategy for menu and Restaurant Details changes, since those now drive nav links and structured data.

Failure modes

• Broken navigation: menu page entry missing, unpublished, or slug-conflicted → footer and featured-menu links break. Previously a hardcoded path masked content errors; now content state is load-bearing.
• Stale or invalid structured data: Restaurant Details partially filled → sameAs incomplete or absent; silent SEO degradation, no error surfaced.
• Injection regression: future template edits that bypass the new script-safe encoding reintroduce the </script> breakout. Mitigate with a rendered-output test, not just a code review.
• Production content pollution: non-interactive install defaulting to sample content in an automated pipeline.
• Asset leakage: placeholder Unsplash/Logoipsum files surviving to production.
• Version drift: upstream moves to a Statamic/Laravel pairing we have not validated; our fork silently falls behind.

Ramp-up

• Developer ramp-up: roughly half a day for a Laravel developer with no Statamic exposure to become productive; Statamic's Antlers/fieldset model is the only real learning curve.
• Editor ramp-up: short CP walkthrough covering Restaurant Details fields, menu page structure, and the social-profile fields that feed structured data — plus an explicit note that slug renames are now safe for nav but still affect inbound links and should include redirects.