Core Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. catchadmin/core sits at the center of CatchAdmin, a batteries-included Laravel admin framework: RBAC, menus, module registration, base controller/model classes, SQL-to-CRUD codegen, import/export, and upload components. The buy decision is not "should we add a library" but "should we adopt an admin framework and its conventions." Choosing it commits the product to Laravel 10/11 + PHP 8.3+ on the backend and Vue 3 + Element Plus on the frontend.
• Time-to-first-CRUD as a roadmap lever. The generator path (SQL CREATE TABLE → backend module, routes, menu entry, Vue list/dialog form) compresses new-entity delivery from days to hours for standard back-office resources. That changes how you sequence a roadmap: breadth of admin surfaces (orders, catalogs, users, reports) becomes cheap; bespoke UX and complex workflows remain expensive.
• Module-per-domain roadmap structure. modules/{ModuleName}/ with Installer.php, a service provider, and routes/route.php gives a clean vertical-slice unit. Roadmaps can be organized and shipped as independently installable modules (php artisan catch:module:install --all), which supports phased rollouts, per-tenant module enablement, and pricing/packaging tiers if the product is sold.
• Data-model conventions are product decisions, not just code style. The framework's conventions — Unix-integer timestamps, unsigned soft-delete columns, status enums starting at 1 with 1 = Enabled / 2 = Disabled, creator_id tracking, $dataRange for data-permission filtering — get baked into schemas and reports. Decide early whether those semantics match your product's audit, timezone, and multi-tenancy requirements; changing them later is a migration project.
• Feature scoping for data-in/data-out. Import (chunked, async via AsyncTaskInterface, $importMaxNum caps, template/history support) and export (sync and async, wired to catch-table's exports prop) are pre-built. This supports roadmap items like bulk onboarding, data migration for new customers, and scheduled reporting without separate build work — or lets you explicitly defer them.
• Storage and file-handling decisions. The upload matrix (local, OSS, COS, Qiniu, chunked resumable, system attachments) front-loads the storage-provider question. Useful for deciding cloud vendor alignment and for regional deployments.
• Adoption-risk management as a standing roadmap item. 5 stars, 0 dependents, and a last release of 2024-09-10 mean this is a single-maintainer, early-stage dependency. The decision it supports is not only "what do we build" but "what do we budget to own." MIT licensing means forking is viable; treat fork readiness and internal expertise as a line item.

When to Consider This Package

Consider it when:

• Your team is already on Laravel (10/11) with PHP 8.3+ and is comfortable with Vue 3 + Element Plus. Adoption cost is lowest when the stack is a match, not a migration.
• The primary deliverable is a back-office / admin surface with many CRUD resources — internal ops tools, ERP or CMS backends, partner/vendor portals, tenant consoles — where consistency and speed matter more than bespoke UX.
• You want codegen from an existing schema as the primary delivery mechanism, e.g., you have legacy tables or a data model defined by a DBA and need admin screens fast.
• Import/export, file upload with cloud storage, and data-permission filtering are on the near-term roadmap and you'd rather not build them.
• You can accept opinionated conventions (base classes CatchController / CatchModel, module layout, Route::adminResource, //next markers) across the codebase, including for engineers who join later.
• You are prepared to own the dependency: pin versions, watch the repo, keep a fork path, and write integration tests around the framework seam.
• Multi-module packaging or per-tenant module toggling is a product requirement.

Look elsewhere when:

• The product is customer-facing, performance- or SEO-sensitive, or requires a design system beyond standard admin patterns. Element Plus admin scaffolding is the wrong primitive.
• The team is standardized on Filament, Laravel Nova, Backpack, or a React/Next admin stack. Those have materially larger ecosystems, hiring pools, and third-party add-on coverage; a 5-star, 0-dependent package is a hard sell against them in a build-vs-buy review.
• You need audited long-term support, a security response process, or contractual SLAs. A single-maintainer package with no dependents and no release in over a year does not provide these.
• You want a composable library, not a framework. catchadmin/core presumes its module layout, base classes, and frontend composables. Retrofitting it into an existing Laravel app with its own structure is high-friction and hard to reverse.
• The backend is API-only / headless or microservice-oriented. This package's value is concentrated in the admin UI and CRUD scaffolding; without that surface you inherit conventions for little return.
• The install flow is a blocker: it expects a sibling frontend repo cloned into web, specific tool versions, .env-driven DB config, and catch:module:install. Fine for greenfield, awkward inside an existing monorepo or CI-controlled provisioning.

How to Pitch It (Stakeholders)

For executives — one paragraph: CatchAdmin Core is a free (MIT) accelerator for building internal admin and back-office software on Laravel. Its value is speed: a new data-management screen that would typically take a sprint can be generated from a database table in hours, and features we would otherwise build — user permissions, menus, bulk import/export, file uploads — come included. The cost is low in license fees but real in two areas: it locks us to a specific technical stack, and it is an early-stage project with a very small community and a single maintainer, last updated in September 2024. Recommendation: pilot it on one internal module with a defined exit path, not an org-wide standard. Budget for the possibility that we maintain a fork ourselves.

For engineering leads: This is an opinionated framework, not a utility package. Adopting it means declare(strict_types=1) everywhere, thin controllers extending Catch\Base\CatchController, models extending Catch\Base\CatchModel with $table/$fillable/$fields/$form/$searchable/$dataRange, Route::adminResource for CRUD, Unix-integer timestamps and soft-delete columns, status enums starting at 1, and a Vue side built on catch-table, useCreate/useShow, and inject('closeDialog'). Upside: strong conventions, SQL-to-CRUD generation, module isolation, and pre-built import/export/upload. Downside: convention lock-in, thin community support (5 stars, 0 dependents), and no recent releases — so we own upgrade and security triage. Mitigations: pin the version, keep domain logic out of framework base classes, and isolate the framework seam behind our own services so a fork or replacement stays cheap.

Ask and success criteria for the pilot: One module, one quarter. Success = a production admin resource shipped, measured against a hand-built baseline for hours-to-first-screen and defect rate; plus a documented answer on fork ownership and an upgrade path. Failure = either the conventions fight our domain model, or the maintenance burden exceeds the velocity gained. Decide the wider rollout on that evidence, not on the framework's feature list.