Core Bundle Laravel Package

Product Decisions This Supports

Feature & roadmap: This package does not drive product features. It is infrastructure glue — a shared utility bundle that other whatwedo bundles depend on. A PM using the whatwedo ecosystem will inherit core-bundle transitively; it is a line item in a dependency review, not a capability a user sees.

Build vs. buy (inverted): The decision it actually informs is build vs. inherit. If your team is assembling Symfony/Laravel-backed admin or back-office functionality from whatwedo bundles, core-bundle is the common substrate you inherit and must plan to maintain. The real build-vs-buy question is whether the wider whatwedo bundle set is worth the vendor lock-in versus assembling equivalent utilities in-house.

Architecture / platform decisions: It serves as a useful reference pattern for how to factor shared code (traits, base services, cross-cutting helpers) out of a family of bundles without circular dependencies. That is a legitimate design input for teams building their own internal bundle ecosystem — study it, don't necessarily install it.

Risk & procurement: This is the primary decision. Six stars, zero downstream dependents, and a description that explicitly frames it as internal ("used by other bundles of whatwedo") means it is an undeclared vendor-internal library. The PM decision is whether to (a) pin and monitor it, (b) fork it, or (c) avoid the dependent bundles that pull it in.

Use cases where it is genuinely relevant: consuming or evaluating the whatwedo bundle family; auditing transitive dependencies before a procurement or security review; structuring a first-party core bundle of your own.

When to Consider This Package

Consider (indirectly) when:

• You are already adopting one or more whatwedo bundles and this appears in your dependency tree — you need a maintenance, pinning, and upgrade plan for it regardless of the star count.
• You are deciding whether to standardize on the whatwedo bundle suite for back-office/internal tooling, and need to judge the ecosystem's maturity and long-term support posture.
• You want a small, MIT-licensed worked example of how to extract shared components across sibling bundles.
• Your architecture review requires documenting every transitive dependency and its bus-factor.

Look elsewhere when:

• You need a stable, community-supported, documented library you can depend on for years. Six stars, zero dependents, and an internal-oriented description are strong signals of a single-team, low-bus-factor asset.
• You are evaluating a Laravel package specifically. The whatwedo family is Symfony-oriented; verify framework fit before assuming Laravel compatibility, and do not assume parity.
• You need explicit API guarantees, semantic versioning commitments, or a published support policy. None are evidenced here.
• You would be adopting it directly for application functionality. It is a utility layer, not a product layer — pulling it in standalone adds maintenance cost with no user-facing benefit.

Practical posture: treat it as a pinned transitive dependency, not a chosen one. Record owner, pin exact versions, and have a fork-and-vendor contingency if a dependent bundle becomes business-critical.

How to Pitch It (Stakeholders)

To executives (30 seconds): whatwedo/core-bundle is an internal shared-utilities library from a third party that sits underneath other bundles we might use. It is not a product capability and not something we would buy or promote on its own. Its strategic relevance is supply-chain: low community adoption (6 stars, 0 downstream dependents) means low external support. The recommendation is to treat it as a managed dependency — pinned, inventoried, with a fork contingency — and to let the decision be driven by whether we actually adopt the parent whatwedo bundles, not by this package.

To engineering: It is MIT-licensed glue that other whatwedo bundles compose from. Expect thin abstraction, no dedicated docs, and a small maintainer team. If we adopt the family, budget for: exact-version pinning, a dependency-owner note in the service catalog, and a spike to confirm framework fit (the suite is Symfony-first; confirm assumptions before any Laravel usage). Useful as a structural reference for factoring shared code across our own bundles; not recommended as a standalone addition to our stack.

Bottom line for the roadmap: No roadmap impact in isolation. Gate any real decision on a parent-bundle adoption review; until then, keep it pinned, documented, and off the critical path.