Core Laravel Package

Product Decisions This Supports

• Build vs. buy the domain core. kreta/core is positioned as the shared foundation of the Kreta ecosystem — contracts, base classes, configuration conventions, and service provider wiring that sibling modules build on. The PM decision it informs is whether to model education-administration primitives (institutions, people and roles, enrollments, academic periods, records) in-house or adopt an existing abstraction and spend roadmap capacity on the layer above it.
• Where the moat actually is. Core domain plumbing is undifferentiated: every competitor needs it, no customer pays for it. If the package holds up, it moves the team's time toward differentiators — workflow automation, reporting, integrations, UX — rather than re-deriving entity relationships and lifecycle rules for the third time.
• Roadmap sequencing and modular architecture. A "core component" package implies a core-plus-modules shape, which supports planning thin vertical slices over a stable kernel: pilot with one institution, then multi-institution rollout, then add modules without re-architecting.
• Platform bet, not a library pick. Because this is a core dependency, adopting it constrains which feature modules, Laravel majors, and PHP versions remain viable downstream. That belongs in an architecture-and-roadmap conversation with engineering, not a routine dependency review.
• Interoperability strategy. If the target market runs Kreta-style systems, aligning internal models to the package's vocabulary lowers the cost of import/export, sync, and migration — otherwise a bespoke mapping project per customer.
• Use cases to validate against: student and institution record management, enrollment and academic-period handling, staff/teacher/administrator role and permission modeling — anything where those primitives are table stakes rather than the value proposition.

When to Consider This Package

Consider it when:

• You are building in the Kreta / education-administration domain, or a structurally similar records-and-roles domain, and need shared domain primitives rather than a finished application.
• Your stack is Laravel/PHP and you want the core to be framework-native so existing team skills apply and feature modules can be composed later.
• You are scoping or prototyping an internal tool and want to anchor terminology and entity structure quickly, accepting that the core may later be replaced or forked.
• You have engineering capacity to audit the source directly — service providers, contracts, composer.json constraints, license, test suite — before any dependency commitment.

Look elsewhere when:

• You need production-grade guarantees. The signals are weak: no stars, no dependents, a one-line description. That is not disqualifying for early-stage code, but it means no community validation, no proven upgrade path, and unclear maintenance cadence.
• You require responsive security patching. With no visible dependent base, assume single-maintainer risk and price in a fork-and-own strategy up front.
• The domain does not actually match. A core package carries opinionated assumptions about entities and lifecycles; forcing a mismatch costs more than modeling from scratch.
• You need batteries-included features — UI, APIs, integrations. A core package will not deliver them, and stacking unmaintained modules on an unmaintained core compounds risk.
• Regulatory or data-protection obligations in your market require auditable, well-documented data handling that an undocumented core cannot demonstrate.

Adoption gate: treat it as an evaluation candidate, not a dependency. Require a time-boxed spike — read the source, run the tests, confirm supported Laravel/PHP versions and the license, and map its domain model against two real customer scenarios — before it enters the architecture.

How to Pitch It (Stakeholders)

To executives: This is a candidate domain core for education-administration products — the shared, non-differentiating layer of records, roles, and academic periods every product in this space needs. If it holds up, it shortens time-to-first-release and lets the roadmap focus on features customers pay for instead of re-deriving the same data model per engagement. The caveat is material and should be stated plainly: the package is unproven — no traction, no downstream dependents, minimal documentation — so the recommendation is a time-boxed technical evaluation, not an adoption commitment. The cost of finding out is small; the cost of building the core ourselves is months.

To engineering: It is Laravel-native and scoped as a core component, so the intended shape is a stable domain kernel with feature modules layered on top — attractive for modular growth. Before we depend on it we need source review, a test-suite run, supported Laravel/PHP versions, a license check, and an honest read on maintenance cadence. Assume we may end up owning a fork and size that accordingly. The decision on the table is "vendor the core and build features" versus "model the core in-house" — and we should decide with code in hand, not from the README. The fallback is genuinely cheap: the narrow slice we actually need is typically a few hundred lines we fully understand and carry no abandonment risk on, so the package has to justify itself against that baseline, not against zero.

To the wider business: The pitch is leverage — buy the boring layer, build the valuable one. The risk is a supply-chain single point of failure in the foundation of the product; the mitigation is a short, gated evaluation now, a named owner for maintenance, and a fork-ready posture if we proceed.