Catchadmin Laravel Package

Product Decisions This Supports

Build vs. buy for the back-office layer. CatchAdmin is a credible "buy" answer for the internal admin surface that every B2B product accumulates: users, roles, permissions, content, attachments, exports, audit/recycle bin. The decision it unblocks is whether the team hand-rolls the 20th CRUD screen or standardizes on a scaffold. Its scope (token auth, permission management, dynamic routes, dynamic tables, paginated API wrapper, resource-level permissions, upload/download, import/export, recycle bin, attachment management) maps almost 1:1 to a typical admin backlog, which makes the make/buy trade-off concrete rather than theoretical.

Roadmap sequencing: platform investment before feature velocity. The framework is modular by design (modules/{Module} on the backend, web/src/views/{module} on the frontend), with CLI tooling (catch:module:install, catch:make:migration, catch:make:model, catch:make:menu, catch:migrate, catch:db:seed). That supports a roadmap decision to spend one milestone building an internal admin platform — module template, menu conventions, permission wiring — and then amortize it across all later admin features instead of re-litigating structure per feature.

Turning a spec into a running admin screen. This is the most PM-relevant capability: the model layer is declarative ($searchable with per-field operators, $fields, $form, $formRelations, sortField, asTree, parentIdColumn), and there is a documented table-definition → migration → model → route → menu pipeline, plus shipped code-generation skills covering codegen, export, import and upload. Practically, a PRD's data dictionary plus field/required/nullable/foreign-key annotations becomes the input that produces the first working list, form and permission entry. That shortens the spec-to-demo loop and gives stakeholders something clickable far earlier in the cycle.

Prioritizing use cases where the framework's opinions are an asset, not a tax. Strong fit: internal ops consoles, supplier/back-office portals, CMS-style content administration, approval and review queues, import/export-heavy data maintenance, and anything needing soft-delete recovery ("data recycle bin") or attachment handling on day one. Weak fit: anything where the admin's look and feel is part of the product's differentiation or where the workflows are the product.

Resourcing and ramp-time decisions. The repo ships AGENTS.md and a set of agent skills (catchadmin-module, catchadmin-backend, catchadmin-codegen, catchadmin-export, catchadmin-import, catchadmin-upload, catchadmin-frontend, catchadmin-install) with explicit conventions — PSR-12, declare(strict_types=1), readonly constructor injection, status 1=Enabled / 2=Disabled, Unix-integer timestamps, unsignedInteger deleted_at instead of softDeletes(). That is unusually agent-legible, and it supports a staffing decision to let mid-level engineers (or coding agents under review) produce convention-compliant modules, with senior time spent on domain logic rather than scaffolding.

Licensing and distribution. Apache-2.0 means commercial use, internal modification and forking are all permissible without a procurement conversation. That removes legal friction from a pilot and preserves the exit option of an internal fork, which matters given the adoption profile (see below).

When to Consider This Package

Adopt when most of these hold:

• The team is already on Laravel/PHP and comfortable with Laravel idioms; CatchAdmin extends rather than replaces them (Catch\Base\CatchModel, Route::adminResource, standard controllers/models).
• The product is an internal-facing or partner-facing admin surface, not the customer-facing money shot.
• Requirements skew CRUD-shaped: list/search/filter, create/edit forms, relations, permissions per resource, exports, uploads, recovery of deleted records.
• You need RBAC, resource permissions, upload/download and import/export in the first sprint rather than as a later epic — these are the highest-value pre-built pieces.
• The toolchain versions are acceptable: Laravel 13+, PHP 8.3+, Vue 3.5+, Element Plus 2.11+, TypeScript strict, Vite 8+, Pinia 3. Note this is a tight, current stack — verify your hosting, CI and any existing shared libraries are compatible before committing.
• You accept a Vue 3 + Element Plus frontend. If your frontend standard is React/Next or a bespoke design system, the "free" admin UI becomes a cost.
• Chinese-first documentation is workable for the team (documentation and ecosystem are Chinese-language; plan for translation or a knowledgeable internal owner).
• You can pin a version, vendor the dependency, and maintain a fork if necessary.

Look elsewhere when any of these dominate:

• Ecosystem and hiring risk are disqualifying. ~940 stars and zero dependents signals a small, effectively single-maintainer project with limited third-party validation. If the org requires vendor support contracts, SLAs, security-advisory responsiveness, or a large hiring pool of people who already know the framework, this fails procurement before it fails engineering.
• You need an LTS-grade, slowly-moving base. The stack targets Laravel 13 / PHP 8.3+ / Vite 8, i.e. a very current baseline; teams standardized on older LTS versions or with long upgrade freezes will fight it.
• The framework would own your domain model. Business logic living in CatchModel subclasses with framework-specific timestamp and soft-delete conventions creates real migration cost later. If the domain is the moat, keep it in app/ and use this only for the admin shell — and be honest about whether the team will actually maintain that boundary.
• UX differentation matters. Element Plus + Tailwind admin components are competent and generic; if the admin experience is a selling point or brand surface, budget for a rewrite of the presentation layer, which erodes the buy case.
• Multi-tenant SaaS at scale, heavy event-driven workflows, or non-CRUD interaction models (real-time, complex wizards, heavy computation). The scaffold's value drops sharply once screens stop looking like tables and forms.
• You cannot afford a spike. Do not adopt on the README. A 1–2 week evaluation that builds two representative modules end-to-end — including one with imports/exports and one with nested permissions — is the minimum bar for a defensible decision.

Decision gate to recommend: run the spike, measure actual time-to-first-working-screen versus the team's current baseline, and record the framework's touchpoints in your codebase. If the spike shows the boundary can be held — domain logic outside CatchModel, presentation isolated in web/ — proceed. If the framework leaks into domain code during a two-module spike, it will leak everywhere.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. CatchAdmin is an open-source (Apache-2.0), modular Laravel + Vue admin framework that already contains the unglamorous 60–70% of every back-office build: authentication, roles and resource-level permissions, dynamic routing and tables, pagination, file upload/download, data import/export, soft-delete recovery and attachment management. Adopting it converts repeated per-feature scaffolding into platform configuration, which should compress the time from approved spec to clickable admin screen — the exact stretch where internal tools usually stall. Licensing is permissive, so there is no procurement cost and we retain the option to fork. The trade-off is deliberate dependency on a small, single-maintainer project with a Chinese-first documentation set and a deliberately current Laravel/Vue stack; we manage that with a pinned version, a vendored copy, and a strict rule that our business logic stays outside the framework. Ask: a two-week, two-module spike with a go/no-go, not a commitment.

For engineering — what you are actually agreeing to. You inherit strong conventions rather than a blank slate: modules/{Module} for backend, web/src/views/{module} for pages, CatchModel with declarative $searchable/$fields/$form, Route::adminResource, Unix-integer timestamps, status 1|2, and unsignedInteger deleted_at instead of Laravel's softDeletes(). The CLI (catch:make:migration|model|menu, catch:module:install, catch:migrate, catch:db:seed, catch:build) and the shipped agent skills mean scaffolding is cheap and reproducible. In return we accept: opinionated data conventions we must not fight per-module, tight coupling to Element Plus on the frontend, a fast-moving upstream we must pin, and the obligation to keep domain logic in app/ Services/Models rather than in framework subclasses. Success criterion for the spike is not "does it work" but "did the boundary hold, and what is our real per-module cost."

Framing the risk honestly. The dependency is real but bounded and reversible: no license lock-in, no per-seat cost, no data escrow concern, and the whole thing is forkable PHP. The residual risks — upstream abandonment, security-patch latency, and convention drift on upgrade — are the standard costs of adopting any scaffold, and they are cheapest to absorb now, at the start, with an explicit fork-and-pin policy, rather than after the admin surface has grown to fifty modules.