Core Laravel Package

Product Decisions This Supports

• Platform foundation vs. buy-in: Whether to standardize internal, data-centric delivery (admin tools, CMS-style content types, configurable catalogs, back-office workflows) on a Laravel-native application engine, or keep paying for bespoke scaffolding on every project. streams/core is the cheapest available test of that hypothesis — the spike cost is days, not a quarter.
• Build vs. integrate vs. fork: The realistic options are (a) adopt the Streams family wholesale, (b) extract its repository/criteria idea and build it in-house over plain Eloquent, or (c) decline. Because streams/core is the engine layer only — the control panel and UI live in sibling repos — "adopt the package" is never a complete option; it is always a slice of a larger multi-repo commitment.
• Roadmap sequencing: Justifies a time-boxed evaluation before committing a team to a shared internal platform. A passing pilot can unlock reusable modules and faster MVP delivery; a failing pilot should kill the dependency early at small cost, which is itself a valuable roadmap decision.
• Use-case qualification: Narrows the candidate surface to low-to-medium-risk internal and prototype work where speed beats vendor guarantees. It should be explicitly excluded from customer-facing, high-scale, or security-critical roadmap items.
• Risk budgeting and ownership: Forces upfront decisions on the unresolved license, named internal code owner, fork-and-pin operating model, security review, and upgrade cadence — all of which have staffing implications a PM must fund, not assume.
• Measurement design: Lets you define go/no-go metrics before the spike: time-to-first-working-app, boilerplate removed, customization effort, upgrade friction, defect rate, developer ramp-up, and total ownership cost versus Filament, Nova, or hand-rolled CRUD.
• Exit planning: Makes reversibility a product requirement. Converting derived schema back into conventional migrations is real work; deciding to budget for it up front is a product decision, not an engineering detail.

When to Consider This Package

Consider it when:

• Your stack is already Laravel/PHP-native and the team wants to test whether a config-driven modeling layer actually removes repetitive scaffolding.
• The product need is user-definable or rapidly evolving data structures — configurable content types, catalogs, internal admin tools — where the modeling paradigm itself is the requirement.
• You can run it as a time-boxed spike behind a clean boundary, scoped to one greenfield module with repository interfaces at the seam, keeping the rest of the app on standard Eloquent.
• You are prepared to own the dependency: legal review of the NOASSERTION license, security review, an internal fork pinned to a known commit, CI, and a documented upgrade policy.
• You accept that 170 stars and zero dependents is not production evidence, and will validate with your own proof-of-concept rather than community signal.
• The comparison case is honest: net of the two-to-four-week learning tax and fork maintenance, does it still beat Filament, Nova, or in-house CRUD?

Look elsewhere when:

• The license cannot be cleared by legal. This is a hard gate, not a checklist item, and it can end the evaluation on day one.
• The package's Laravel/PHP support window would force you off your standard runtime, and forking to widen constraints isn't funded.
• You need commercial support, SLAs, vendor accountability, or a hiring pool — none of which exist here.
• The product is customer-facing, high-scale, or security-critical.
• The codebase expects app/Models to be the source of truth; Streams becomes a competing persistence paradigm, and you'd inherit coupling and exit cost for little gain.
• You want the UI. The developer-facing value sits in streams/ui and streams/platform; adopting those means a second stale dependency, and a thin in-house admin surface is usually cheaper.

How to Pitch It (Stakeholders)

Executives: streams/core is an open-source Laravel application engine that could accelerate internal, data-centric delivery by replacing hand-written scaffolding with configuration. The case is real but unproven: modest traction (170 stars), no dependent packages, no vendor, and an unresolved license. The ask is not adoption — it is a short, low-cost evaluation with legal review and explicit success criteria, plus a documented exit path. Frame it as buying an option on a platform strategy at the price of a sprint.

Engineering: Position it as a bounded experiment, not foundational infrastructure. It is an application engine, not a package — adopting it means adopting its vocabulary (streams vs. migrations, assignments vs. columns, criteria vs. scopes, repositories vs. models) and likely forking it to widen Laravel constraints. The spike should prove one stream with two field types, one criteria-based query, one write path, and one measured upgrade attempt, with the same contract tests you'd write for an Eloquent implementation. Assume you own maintenance from day one and that the exit is a rewrite of derived schema into migrations.

Recommended decision ask: Approve a two-day technical spike plus a license and maintainer-activity review, with go/no-go gates on delivery speed, maintainability, security, and total ownership cost. If the gates don't clear within the sprint, the fallback is to build the repository/criteria abstraction in-house — you keep the good idea and drop the dependency risk.