Acacia Laravel Package

Product Decisions This Supports

• Build vs. buy vs. generate for internal admin tooling. Acacia sits between "hand-write every CRUD screen" and "buy a maintained admin framework." It scaffolds models, controllers, routes, views, and an admin layout from publishable stubs and config, then hands you the code. The PM decision should be framed as a three-way comparison — hand-build, generate-and-own, or license Filament/Nova/Backpack — and priced across a 12–24 month horizon, not on the demo.

• Roadmap sequencing for low-differentiation surfaces. This is the right tool for work where speed beats polish: user/account management, content moderation queues, ops dashboards, support lookup tools, and MVP back-office screens that unblock demos, QA, and sales onboarding. It is the wrong tool for anything on a revenue or customer-experience path. State explicitly in the roadmap narrative that the admin panel is not a differentiator — otherwise someone will try to "productize" the scaffolded UI later and you'll pay for a redesign.

• Sizing the back-office epic. The package ships an opinionated surface — auth, permission-ready access control (via spatie/laravel-permission), configurable dashboard and navigation, search/sort/pagination — so an epic can plausibly be scoped in days rather than sprints. That estimate is contingent on a passed compatibility spike. Do not put those dates on the roadmap before engineering confirms the stack pin: last release May 2022 (Laravel 9.2 era), 43 stars, zero dependents.

• Vendor posture and lifecycle risk as an explicit portfolio call. Treat Acacia as a scaffold to fork or vendor, never a platform bet. The decision is binary: does generated code become team-owned on day one with a named owner and a documented exit path, or is a maintained alternative cheaper over two years? The exit test is clean — because config, stubs, views, migrations, and generated resources live in your repo, deleting the composer dependency should leave a working (if less convenient) app. Protect that property deliberately: commit every generated file, never gitignore the output.

• Security and compliance gating. v1.4.0's sole change was adding a default admin user to the Users Seeder. Before anyone runs migrate --seed outside local, that seeder must be env-sourced, hashed, firstOrCreate, and environment-gated. If it isn't, that's a predictable privileged account and a pentest finding — potentially a launch gate depending on compliance posture. This is a PM-visible risk, not a detail to delegate.

When to Consider This Package

Adopt when:

• The work is internal-only tooling (ops, moderation, support, user admin) where functional beats designed.
• The team is on, or can pin to, Laravel 9.x/PHP 8.1-era constraints and is willing to fork-and-patch every future Laravel major.
• You want generated code to be first-party and reviewable, with no runtime lock-in to a third-party admin framework.
• You have a named owner for the fork and a runbook that includes the permission-cache reset and Tailwind content globs.
• A time-boxed spike (one boring model — name, status, a foreign key) measured against the ~2–4 hours a competent Laravel dev spends hand-building the same CRUD comes out favorably.

Look elsewhere when:

• You're on Laravel 10/11 or PHP 8.3 and can't afford a compatibility branch.
• The surface is customer-facing, needs a design system, or will be iterated on by product/design rather than engineers.
• You need active upstream maintenance, security patches, or a support contract — zero dependents and a single maintainer mean there is no upstream.
• The front-end stack matters: docs describe both Vue 3/Inertia/Tailwind 3 and Blade-rendered views. Those are completely different integration jobs (Vite aliases and Tailwind globs vs. published views and purge paths). Resolve this on a spike branch before estimating — don't trust the README.
• You'd be relying on regeneration to pick up changes. Re-running the generator will likely clobber your work; the operating model is one-shot codegen followed by hand-editing the stubs.

How to Pitch It (Stakeholders)

For executives: Acacia is a free (MIT) Laravel code generator that turns "hand-write every admin CRUD screen" into "generate a baseline, then own it." It's a velocity play for internal back-office tooling — the surfaces that unblock demos, QA, and support workflows but don't win customers. The realistic return is roughly 30–60 minutes per simple resource after the first, versus 2–4 hours hand-built, and it comes with auth, roles/permissions, navigation, and search/sort/pagination out of the box.

The honest caveat: it's dormant. Last release May 2022, 43 stars, no dependents, effectively one maintainer. So we're not adopting a platform, we're adopting a stencil. We pin the version exactly, fork the pieces we need, name an owner, and keep everything it generates committed in our repo so we can walk away cleanly. Risk is bounded by the exit test: if the package vanished tomorrow, we still ship. The one non-negotiable is fixing the default admin seeder before it ever touches a non-local environment.

For engineering: Treat generation as one-shot codegen, not a runtime framework. The leverage is in the stubs — spend one afternoon hardening them (scoped, index-aware search filters; paginate(25)->withQueryString(); authorization in policies rather than inline can: middleware; ordering on an indexed column) and every future resource inherits it. Navigation stays declarative in config so the menu never drifts from routes. RBAC lives in seeders and policies, never scattered hasRole checks. Never edit vendor/ — copy and bind instead. Pin 1.4.0 exactly, commit every generated file, and document who owns the fork.