Factory Laravel Package

Product Decisions This Supports

• Demo and prototype velocity. Lets the team spin up realistic Statamic content (entries across collections, with taxonomies and fields) in minutes instead of hand-authoring placeholder content, which shortens the loop from "idea" to a clickable stakeholder demo.
• Build vs. buy for internal tooling. Replaces a bespoke seeder/artisan command with an MIT-licensed addon. The decision is really "spend a few hours writing our own faker wrapper" vs. "adopt and pin a small dependency" — favor writing our own unless the team is already Statamic-native and time-boxed.
• QA and pre-release testing. Supports integration tests and staging fixtures that need real Statamic entries rather than mocked data, improving confidence in templates, listing pages, and search/filter behavior.
• Onboarding and documentation. New engineers and content editors get a populated local site on day one, reducing environment-setup friction and support tickets.
• Roadmap inputs. If demos and content seeding are recurring needs across projects, this is evidence for a shared internal "content fixtures" utility rather than per-project scripts; if it's a one-off, it stays a dev convenience.
• Explicitly not supported: production content workflows, editorial migration, or anything requiring deterministic, auditable content. This is a developer-environment tool.

When to Consider This Package

Consider it when all of the following hold:

• The project is on Statamic v3/v4/v5 with Laravel; otherwise the addon is irrelevant. Statamic 5 support now rests on the v1.5.1 patch, which bumped stillat/primitives to fix Statamic 5 compatibility — so anything below v1.5.1 should be treated as broken on Statamic 5.
• You need repeatable fake entries across multiple collections, with field data, relationships, and taxonomies — enough structure that hand-writing seeders becomes tedious.
• Usage is confined to local, CI, or staging environments, gated behind APP_ENV checks.
• The team accepts a small, single-maintainer dependency for non-critical tooling, plus its transitive stillat/primitives dependency (a second small package in the supply chain, and the actual source of the recent compatibility break).

Look elsewhere — or write a ~50-line custom seeder — when:

• Low adoption is a blocker. 19 stars and 0 dependents is weak social proof; there is no ecosystem validation, no third-party tutorials, and effectively no community support channel. Treat any bug as yours to fix.
• Maintenance risk matters. The v1.5.1 patch shows the maintainer is still responsive and does ship compatibility fixes, which is a mild positive signal — but it is still a single maintainer with no dependents, so the bus factor remains real. If Statamic ships breaking changes, expect a lag or a fork.
• Compatibility fixes matter to your upgrade plan. v1.5.1 is a compatibility-only patch: no new features, no API changes, no deprecations. It unblocks Statamic 5 upgrades, but it does not change the package's capabilities or maturity.
• You need production-grade or deterministic content. Use versioned fixtures, a content migration strategy, or Statamic's own import tooling instead.
• Your content model is simple. One collection with three fields does not justify a dependency.
• You have compliance, security review, or SBOM requirements that make unmaintained dev dependencies expensive to justify — remember to account for stillat/primitives in that review, not just this package.

Mitigations if adopting: pin to v1.5.1 or later (earlier pins are incompatible with Statamic 5), vendor or fork it including its primitives dependency, wrap all calls behind your own seeder command so it can be swapped out in an afternoon, and never register it in production config.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed developer utility that generates placeholder content for Statamic sites, so we can produce realistic demos and test environments faster and with less manual effort. The cost is near zero and the upside is a shorter path from prototype to stakeholder review. The latest release (v1.5.1) is a maintenance patch that keeps it working with Statamic 5 — a good sign that the maintainer is still around, but it does not broaden what the tool does. The caveat is maturity: it has a very small user base and a single maintainer, so we should treat it as an internal developer convenience rather than infrastructure. Recommended posture: trial it on one project behind a small wrapper, with no production dependency.

For engineering: It is a thin Faker-driven layer over Statamic's entry APIs — low conceptual surface area, low integration risk, but also low leverage. v1.5.1 contains no new features or breaking changes; it only bumps stillat/primitives to restore Statamic 5 compatibility, which means (a) pin at least v1.5.1 if you are on Statamic 5, and (b) the compatibility risk is now one level removed, sitting in a transitive dependency we don't control. Adopt only if it demonstrably beats a hand-rolled seeder for your content model; otherwise the custom command is cheaper to own. If adopted, pin the version, isolate it behind a single SeedDemoContent command, guard it to non-production environments, and assume we own maintenance. Budget half a day for the evaluation and expect to fork if upstream goes quiet.