Crazyphp Laravel Package

Product Decisions This Supports

• Build vs. buy / adopt vs. defer: CrazyPHP is a pre-1.0 application scaffold ("my crazy framework for creating ultra-fast webapps," v0.10.0) — not a drop-in library. The decision it informs is a framework/foundation choice, not a small dependency addition. Keep the recommendation open until a hands-on spike confirms what it actually replaces.
• Greenfield vs. brownfield fit: The package is opinionated — MVC conventions, routing, view rendering, a database layer, and CLI/scaffolding utilities. It wants to own project shape, so it competes with a Laravel skeleton rather than augmenting one. This is a candidate for a new, small, internal service; it is a poor fit for bolting onto an existing Laravel codebase.
• Prototype and internal-tooling scoping: Reasonable for spikes, admin/back-office tooling, and learning projects where a rewrite is cheap and reversible within a sprint. Not defensible for customer-facing, revenue-bearing, auth-boundary, or regulated surfaces without evidence the release notes do not provide.
• Roadmap sequencing: v0.10.0 ships a changelog link only — no features, no fixes, no breaking-change callouts. Migration cost and API stability cannot be inferred from the release, so schedule a short evaluation spike rather than committing a milestone.
• Maintenance budget as a line item: Rapid 0.x minors (0.9 → 0.10) mean the public API is still moving. Price in exact pinning, diffing at each bump, a named upgrade owner, and a fork/replacement contingency at 1.0. This is not a free dependency.
• Vendor-risk and exit-planning decision: One GitHub star, zero dependents, a single maintainer, and link-only releases are weak external-validation signals. Any adoption should be behind an adapter so the package is swappable, with the exit cost written down before the first commit.
• Use-case discovery still open: The upstream description and docs must drive the feature-fit call. Without a readable release, this assessment can only gate how you would adopt it, not assert which product capabilities it unlocks.

When to Consider This Package

Consider it when:

• The need is internal, non-critical, and reversible within a sprint — scaffolding, prototypes, admin/back-office, internal tooling.
• You can commit an engineer for a 1–3 day spike in a throwaway repository to read the source, run the tests, and build one vertical slice (entity → persistence → endpoint → UI).
• You can pin the exact version (0.10.0) with a committed lockfile and vendor, mirror, or fork it so an upstream 0.x minor cannot break production mid-sprint.
• A named owner accepts the per-release upgrade-and-review burden, including reading the diff as the changelog.
• License, dependency tree, and composer audit check out clean, and PHP/Illuminate version ranges match your runtime matrix.
• You treat any separable part (e.g., the generator) as a build-time tool with output committed as ordinary source — this cuts long-term runtime exposure sharply.

Look elsewhere when:

• The package would sit on a critical path, handle payments or auth boundaries, or touch regulated data.
• You need a stability guarantee, LTS window, or SemVer contract — a 0.x line offers none, and minor bumps are permitted to break.
• Release notes stay link-only across several versions; that is a maintainer-process signal, and you should price it in.
• Bus factor is unacceptable: single-maintainer projects with thin changelogs carry abandonment and security-response risk you cannot contract away.
• You are adding to a mature Laravel application where its conventions, service providers, and generated artifacts would collide with hand-written structure.
• A first-party Laravel/Symfony component covers ~80% of the need — prefer the framework primitive over an unvetted wrapper.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are tracking a small, pre-1.0 PHP framework at v0.10.0 with one GitHub star, no downstream dependents, and a release that ships no readable summary of what changed. We are not recommending adoption on any revenue-bearing surface. The recommendation is a time-boxed, isolated evaluation spike against a pinned version, after which we return with a build-vs-buy call, a total-cost-of-ownership estimate (upgrade labor, fork contingency, onboarding tax), and a go/no-go. The spike is cheap; adopting an unvetted 0.x framework into a critical path is not.

To engineering: Pin 0.10.0 exactly — do not float to ^0.10. Diff v0.9.0...v0.10.0; the diff is the changelog. Confirm the PHP/Laravel support matrix, test and CI posture, license, and open-issue trend. Spike in a disposable repo to establish what it replaces and whether we would be comfortable owning a fork. Until then it stays out of shared/core dependencies and lives behind an adapter so it is swappable. Treat the package as a build-time scaffold where possible, with generated output committed as normal source, and write down which files are generated versus hand-edited so upgrades do not become merge exercises.

Framing line for the room: Pre-1.0, unsummarized release, plausible utility for greenfield internal work — evaluate cheaply, adopt narrowly, and keep an exit.