Crazyphp Laravel Package

Technical Evaluation

What we are evaluating. kzarshenas/crazyphp (repo kekefreedog/CrazyPHP) is a pre-1.0, ~1-star, zero-dependent PHP micro-framework positioned as "my crazy framework for creating ultra-fast webapps." It ships an MVC skeleton, router, view layer, DB/CRUD layer, and CLI/config utilities. The v0.10.0 release notes are a compare link only — no summary, no breaking-change callouts, no migration guidance.

Architecture fit — the core finding. This is not a Laravel package; it is a Laravel competitor. It wants to own the project skeleton, directory conventions, and code-generation workflow. That inverts the usual "package" evaluation: if our platform standard is Laravel, adopting CrazyPHP is a stack decision, not a dependency decision, and it should be evaluated at that altitude or not at all. Two coherent postures:

• Build-time tool (low exposure): use the CLI once to scaffold, commit the generated source as ordinary PHP, and drop the runtime dependency. This is the only posture where the leverage is real and the exit is cheap.
• Runtime foundation (high exposure): adopt it as the application framework for a greenfield service. Justifiable only for internal, reversible, low-blast-radius work.

Integration feasibility. Composer install is trivial; the unknowns are the blockers. Unverified: PHP version ceiling, any Illuminate coupling, template engine dependencies, whether the CLI assumes ownership of project root, test coverage, CI posture, license, and security disclosure path. With zero dependents in the wild, there is no community evidence of edge-case behavior — we would be the first mover, which means we absorb first-mover costs.

Technical risk — high, and lifecycle-driven rather than quality-driven.

• SemVer ambiguity: at 0.x, minor bumps may break. ^0.10 is unsafe; only an exact pin plus committed lockfile is defensible.
• Opaque releases: no changelog means we cannot scope regression testing or estimate upgrade labor. This is the dominant unknown and it is a process signal, not a one-off.
• Convention lock-in: generated artifacts couple the codebase to upstream templates; post-upgrade divergence produces low-signal diffs and subtle runtime faults.
• Bus factor 1: abandonment and security-response capacity are unmitigated risks.
• Ecosystem thinness: 1 star / 0 dependents means no Stack Overflow corpus, no third-party plugins, no hiring pool.

Key questions to close before any commitment.

1. What actually changed v0.9.0 → v0.10.0, and were any changes breaking?
2. Supported PHP and Laravel/Illuminate ranges; stated path and criteria for 1.0.
3. Is the intent to replace a Laravel skeleton or be consumed inside one? (Upstream positioning is ambiguous.)
4. Test coverage, CI status, license, security disclosure process.
5. Documented upgrade procedure for generated projects — regenerate vs. patch.
6. Metadata hygiene: confirm release provenance/date and that the v0.10.0 artifact matches the tag.

Integration Approach

Stack fit. Acceptable only where (a) the team is already PHP/Composer-native, (b) the surface is internal, non-critical, and reversible within a sprint, and (c) we are willing to treat CrazyPHP conventions as a project-local standard. It is a poor fit where organizational leverage comes from Laravel idioms, transferable skills, or a broad vetted package surface. The value proposition — less boilerplate for structured CRUD apps — is real but reproducible with ~200 lines of Laravel scaffolding we already own.

Migration path. No in-place migration of an existing application. Two viable paths, in priority order:

• Adjacent / build-time: run the generator in a sandbox, evaluate output quality, commit the result as normal source. Runtime dependency drops to zero — this converts an unvettable dependency into a one-off code review, which is a far better TPM trade.
• Greenfield foundation: disposable repo, exact-pinned 0.10.0, one vertical slice (entity → persistence → endpoint → view) as the acceptance test. Timebox 1–2 engineering days.

Compatibility. Must be established empirically, not from release notes. Concretely: PHP constraint vs. our runtime matrix; Illuminate range and conflicts; collisions with global helpers, autoload maps, and service providers; CLI install mode (dev-only vs. global) and CI behavior under lockfile pinning. Resolve all of it in a throwaway branch.

Sequencing.

1. Now: request the diff summary and version-support matrix. Do not upgrade anything in flight on an unexplained release.
2. Spike (1–2 days, one engineer): isolated repo, exact pin, one vertical slice, written friction log covering lock-in surface, generated-vs-handwritten boundary, and exit cost.
3. Gate: proceed only if the slice completes cleanly and question 1 is answered. Otherwise defer — no cost incurred beyond the spike.
4. If approved: exact pin, committed lockfile, internal mirror/vendor-fork, named owner, written convention standard, CI pins the CLI tool separately from require.
5. Re-evaluate at 1.0, or at the first release with a real changelog.

Operational Impact

Maintenance — the dominant cost line. A pre-1.0 dependency with link-only releases transfers triage work to us. Budget two recurring items: a version-review ritual (read the diff, since notes carry no signal) and lockfile hygiene. Generated code multiplies this — a single upstream template change can produce a wide, mechanical, low-review-value diff across the codebase. Estimate this as engineering days per year, not as a free dependency, and put it in the TCO slide.

Support. Community-supported, single maintainer, no LTS, no SLA. Acceptable for a pilot; unacceptable as an unmitigated critical-path dependency. Mitigations: internal mirror, at least one engineer able to read and patch the source, and an exit plan that distinguishes portable assets (generated PHP source) from non-portable ones (runtime coupling to framework conventions). Know which one we depend on — that determines whether an upstream disappearance is a delay or an outage.

Scaling. Runtime scaling inherits the underlying PHP execution model and is not a differentiator; the framework does not plausibly deliver an order-of-magnitude gain over a tuned Laravel app, and we should not let "ultra-fast" in the description drive a performance-led decision without benchmarks. The real scaling constraint is organizational: CrazyPHP competencies are non-transferable, so onboarding cost grows linearly with headcount while our hiring pipeline (Laravel/PHP) does not offset it.

Failure modes to plan for.

• Silent behavioral break on a minor bump, with no changelog warning.
• Constraint drift resolving to an untested patch in a fresh install.
• CLI toolchain breaking in CI after an upstream release — pin the tool independently.
• Generated artifacts diverging from package expectations mid-upgrade → subtle runtime faults.
• Upstream abandonment: no releases, no security fixes, no answers.
• Upstream license/ownership change with no governance recourse at this size.

Ramp-up. Expect meaningful onboarding even for strong Laravel engineers, because CrazyPHP conventions must be learned and Laravel habits partially unlearned. Without a written standard defining which files are generated (never hand-edited) and which are hand-written, teams will drift into editing generated code, and the next upgrade becomes a merge exercise. That document is a prerequisite to scaling past one team.

TPM recommendation — Hold / conditional pilot. Do not promote v0.10.0 into a production path on the strength of a compare link. The package may be a reasonable greenfield scaffold; the blocker is not the release, it is the absence of information about the release, compounded by zero external usage. Leverage it as a scaffolding tool with portable output if at all, run a two-day pinned spike, and return with a build-vs-buy call plus a TCO estimate. Framing line for stakeholders: pre-1.0, unsummarized release, no external dependents — possible utility, unproven; evaluate cheaply, adopt narrowly as a build-time tool, and keep a hard exit.