Admin Generator Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. This package is best framed as a buy-side accelerator for the build option: it doesn't replace your application, it removes the repetitive first pass of controllers, routes, Blade views and form requests for each Eloquent model. The decision it informs is not "adopt a platform" but "do we hand-write the hundredth index/create/edit screen, or generate a first draft and customise it?"
• Time-to-first-demo for internal tools. For back-office dashboards, ops data-entry screens and MVP admin panels, a generator can compress days of boilerplate into hours. That changes the calculus on whether a small internal tool is worth building at all — cheap enough to build, cheap enough to throw away.
• Roadmap sequencing for "invisible" work. Admin CRUD is rarely on a public roadmap but consumes real sprint capacity. If a generator credibly removes even 30–40% of that effort on suitable models, it's a candidate for a tooling spike ahead of a quarter heavy in internal-tool requests.
• Standardisation of internal UI. Generated screens are consistently AdminLTE-style with uniform index/create/edit/delete flows and validation handling. That is a product decision as much as a technical one: consistent internal tools reduce support load and training time for ops staff.
• Scope boundary: prototyping vs. product. The output is plain PHP/Blade you own and edit, so the useful framing is "scaffold once, then maintain as normal code." It supports decisions to prototype internal panels quickly; it does not support decisions to build customer-facing or compliance-sensitive surfaces on a generated foundation.
• Explicit non-decision. Given zero stars, zero dependents and a last release of May 2020, this is not a signal to standardise an admin strategy on the package. The product decision it should trigger is a timeboxed evaluation, not a commitment.

When to Consider This Package

Consider it when all of the following hold:

• You are on (or pinned to) Laravel 7 and already use, or are willing to adopt, savannabits/craftable — the generator is written specifically for that companion package, and that coupling is not optional.
• The target is an internal, low-risk surface: admin dashboards, ops back office, data-entry screens, internal MVP demos.
• The screens are CRUD-shaped and map cleanly onto Eloquent models and relationships — index listings, create/edit forms, validation, delete.
• You have Laravel-fluent engineers who will read, review and own the generated code. The generator produces a starting point; the maintenance burden transfers to you immediately.
• The work is short-lived or deliberately disposable, or you accept that you are effectively forking the generated output.
• You need volume: many similar models where the per-screen savings compound, rather than one bespoke screen.

Look elsewhere — or plan to hand-roll — when:

• You are on Laravel 8 or later. The package targets Laravel 7 and has had no release since May 2020; there is no evidence of maintenance against current framework versions. Treat it as incompatible until proven otherwise.
• You are not using craftable. The description explicitly scopes the generator to savannabits/craftable; without it, this is the wrong tool.
• The surface is customer-facing, security-sensitive, audited or regulated. A generator that emits auth-adjacent admin screens from a stale, zero-adoption codebase is not a defensible foundation.
• You need a supported dependency: vendor responsiveness, security patches, an upgrade path. Zero stars and zero dependents mean no community backstop and no observable maintenance signal.
• Your admin needs are bespoke — complex workflows, custom permissions, heavy interactivity. The generator's value is standardisation; where you need differentiation, it becomes something to fight.
• The team would have to learn craftable plus the generator plus Laravel 7 to save a few days of boilerplate. The onboarding cost exceeds the payoff.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a code generator, not a platform. It turns existing database models into ready-made internal admin screens — lists, forms, validation — so engineers skip the repetitive first pass on back-office tooling. The output is ordinary Laravel code we own and can edit freely, so there is no lock-in to the tool itself. The catch is maturity: the project has essentially no adoption, no releases since 2020, and targets Laravel 7. Recommendation: do not adopt it as a dependency or a standard; run a small, timeboxed spike on a disposable internal tool to measure the actual hours saved, and if it pays off, treat the generated code as a one-time scaffold we then own.

For engineering — the honest summary. Mechanically it's a standard Composer install that scaffolds controllers, routes, Blade views and form requests from a model definition, with configurable field types, validation rules and relationship handling. AdminLTE-style output, plain PHP/Blade, freely editable afterwards. Three caveats to weigh before anyone touches it: (1) the version note — v7.0.0 tracks Laravel 7, not "Laravel 7 and up," so verify the actual illuminate/* and php constraints with composer show -a before installing anywhere real; (2) the coupling — it assumes craftable's base controller, layout and asset pipeline, so a bare Laravel app yields files that render without the admin chrome; (3) regeneration overwrites. Commit raw generator output as its own commit before customising, keep field definitions in version control, and push table-specific logic into form requests, model accessors and Blade partials so a regenerate-and-diff stays readable. Generated validation is baseline only — unique: with ignore(), exists: on foreign keys and file rules need adding in the same PR. Budget for the three things the generator typically leaves to you: menu registration, permissions/route guards, and multi-select pivot sync. If the spike proves out, plan to vendor or fork the package so we control the stubs rather than depending on an unmaintained upstream.