Statamic Jobs Laravel Package

Product Decisions This Supports

• Build vs. buy for a careers/job listings surface. This addon (jonassiewertsen/statamic-jobs) gives a Statamic site a job-postings content model and front-end listing out of the box. The decision it informs is whether a careers page is a two-day configuration task or a multi-sprint custom build.
• Platform upgrade timing (the actual driver of v1.5.0). The release adds Statamic 5 and Laravel 11 support. If your roadmap includes a Statamic/Laravel upgrade, this package moves from "blocker" to "non-issue" in the dependency audit. That directly affects upgrade sequencing and the risk column of the upgrade plan.
• Content ownership of the careers section. Because job data lives in Statamic (flat-file/content-first), HR or marketing can publish, edit, and retire postings without engineering involvement. This supports an operating-model decision: keep recruiting content with the content team rather than in the product backlog.
• Scope boundary for ATS investment. Choose this package when the requirement is publishing roles, not managing candidates. It clarifies that candidate pipeline, screening, and compliance stay with an ATS (Greenhouse, Lever, Workable, etc.) and keeps that integration out of v1 scope.
• Vendor/dependency risk posture. Active compatibility maintenance on a solo-maintained addon is a positive signal for a low-criticality marketing surface, but not sufficient for anything on a revenue-critical path. Feed this into your dependency register.

When to Consider This Package

Adopt when:

• You are on, or upgrading to, Statamic 5 / Laravel 11 — v1.5.0 is the release that makes this viable; older versions would pin you back.
• You need a modest careers page (tens of postings, not thousands) inside an existing Statamic site, and want it shipped in days.
• Editors own the content and you want to avoid a bespoke admin UI.
• Requirements are publishing-centric: listing, detail pages, department/location taxonomy, maybe a simple application email or form link.

Look elsewhere when:

• Your stack is not Statamic (plain Laravel, WordPress, Next.js). The value here is largely the Statamic content model; a non-Statamic build gains little.
• You need ATS-grade workflows: candidate records, statuses, interview scheduling, GDPR/CCPA retention, EEOC reporting. Buy an ATS and link out.
• You need high-volume job boards or marketplaces: faceted search, saved searches, programmatic SEO across thousands of pages, multi-tenant employer accounts, structured data feeds to Indeed/LinkedIn.
• Maintenance risk is unacceptable. Verify the maintainer's responsiveness and release cadence against your support policy; confirm the license terms and whether you can vendor/fork if abandoned.
• You need deep customization of the data model — check the addon's blueprint/fieldset assumptions early rather than fighting them later.

Before committing, verify in a spike: PHP/Laravel/Statamic version matrix, whether the addon's blueprints are overridable, how application submissions are handled and stored, upgrade path and migration notes from v1.4.x, and test coverage.

How to Pitch It (Stakeholders)

For executives: We can stand up a careers section on our existing Statamic site using a maintained, low-cost addon instead of a custom build — roughly days of effort rather than a sprint or two, and it removes a dependency blocker from our upcoming Laravel 11 / Statamic 5 upgrade. It handles publishing job postings, not recruiting operations — candidate management stays in our ATS, so this is a small, contained commitment with no new system to own.

For engineering: v1.5.0 adds Statamic 5 and Laravel 11 support, which clears the package in our upgrade audit and means we don't need to fork or pin. It's a thin addon over Statamic's content layer — configuration and templates, not a parallel data model — so the surface area we'd own is small and the exit cost is low: content is portable and we can replace the rendering layer if we ever outgrow it. Recommended action is a short timeboxed spike to confirm blueprint overridability and the submission flow before we commit it to the upgrade plan.