Streams Distribution Laravel Package

Product Decisions This Supports

• Build vs. buy on the data-modeling layer. This package only makes sense as part of the Streams Platform (Anomaly Labs' Laravel-based content/data modeling engine, also the foundation of PyroCMS 3). The decision it informs is whether to adopt Streams as the substrate for admin CRUD, content types, and custom data structures instead of hand-rolling models, migrations, and admin screens. The distribution addon is the packaging half of that decision — not the engine itself.
• Productizing a repeatable baseline. A "distribution" in the Streams ecosystem is essentially a versioned bundle: a declared set of addons, streams/fields, migrations, and seed data that can be installed as one artifact. If your roadmap includes multiple deployments (per-client instances, vertical variants, demo/sandbox environments), this supports the call to invest in a reusable, versioned application baseline rather than per-deployment customization.
• Roadmap sequencing: template strategy vs. bespoke delivery. Choosing a distribution means committing to "configure once, ship many." Choosing not to means every deployment is a bespoke build. That's a resourcing and margin decision as much as a technical one.
• Time-to-market for internal tools and admin surfaces. Through Streams, this indirectly supports faster delivery of back-office screens and data entry flows, which often sit on the critical path for launching a customer-facing feature.
• What it does not support: any end-user-facing capability. This is infrastructure and packaging. It won't unlock a roadmap item, differentiate the product, or be visible to a customer. Treat it as a delivery-cost lever, not a feature.

When to Consider This Package

Consider it when:

• You have already committed to the Streams Platform / PyroCMS 3 ecosystem. This is an addon with a hard upstream dependency; on its own it does nothing.
• You genuinely ship the same application shape more than once — multiple clients, environments, regions, or vertical editions — and you're currently maintaining parallel forks or a manual setup checklist.
• You want a versioned, installable baseline without writing your own installer, addon registry, and seeding orchestration.
• Your team is small and can absorb reading the source as documentation. With ~3 stars and 0 dependents, community support, tutorials, and Stack Overflow answers effectively do not exist.

Look elsewhere when:

• You are not on Streams. Use plain Laravel migrations and seeders, or a starter kit approach; for admin CRUD, evaluate Filament or Laravel Nova; for content modeling, evaluate Statamic. All have materially larger communities and hiring pools.
• You have a single deployment or single tenant. The distribution concept is overhead; migrations plus seeders cover it.
• You need vendor SLAs, predictable release cadence, or security responsiveness. A 3-star, zero-dependent package in a niche ecosystem is a bus-factor risk you must own.
• You are on a recent Laravel major. Anomaly packages have historically lagged framework releases — verify compatibility against your target version before it enters a design doc.

How to Pitch It (Stakeholders)

To executives: This isn't a feature — it's a factory. It lets us ship the same baseline application to many customers or prospects faster, with less bespoke setup per deployment, which is a gross-margin story rather than a product story. The catch is concentration risk: it sits in a very small, single-maintainer ecosystem with negligible adoption, so we'd be betting delivery efficiency on a dependency we may have to fork and maintain ourselves. Recommendation: pursue only if we are already standardized on Streams; do not adopt Streams in order to use this.

To engineering: Treat it as a packaging layer, not a framework. Pin the version, vendor or fork it, keep it behind a boundary so domain code never imports it directly, and budget explicit ownership for upgrades since upstream release cadence is unpredictable. If we adopt it, the first deliverable is a documented "how we ship a distribution" runbook — not a proof of concept.

Net PM position: Low strategic value, narrow applicability, real maintenance tail. Green-light only as a cost-reduction move inside an existing Streams footprint; otherwise it's a distraction from the build-vs-buy decision that actually matters.