Tardis Laravel Package

Product Decisions This Supports

• Build vs. buy for internal back-office tooling. Tardis supplies the scaffolding most internal admin panels end up rebuilding: BREAD (Browse/Read/Edit/Add/Delete) resources declared in JSON, list/view layouts, search, sort, filters, soft deletes, row and bulk actions. The decision it informs is "do we spend 4–8 engineering weeks on an admin CRUD layer, or pilot this and spend that time on domain logic?"
• Standardizing an admin surface across products. The plugin system (assets, routes, settings screens), menu builder, widget dashboard, and data-driven themes with a theme editor mean one panel can host multiple feature areas instead of each team shipping its own ad-hoc screens. That is a platform/consolidation decision, not a feature decision.
• Access control as a default, not a project. access admin authorization is on out of the box, with a permission tree and super-admin seeding on install. This supports roadmap items that would otherwise stall on "who is allowed to see this screen?" — relevant for anything customer-support-facing or finance-adjacent.
• Localization roadmap. English and Turkish panel strings plus translatable content with locale tabs signals a genuinely bilingual target. If Turkish-language markets or bilingual internal ops are on the roadmap, this is a differentiator that most Laravel admin packages treat as an afterthought.
• Operational tooling decisions. The log viewer and the allow-listed command runner (off by default) are a "do we build our own ops console, or adopt this and lock it down?" call. The safe-default posture (disabled until enabled, allow-list only) is the right shape for a PM to defend in a security review.
• Feature-flag / scoping decisions. The known limits are directly decision-relevant: no drag-and-drop or nested menus means information architecture must stay shallow; required translatable fields demanding a value in every locale means content-entry workflows need either a relaxed validation setting or a deliberate "all locales required" policy. Decide the policy before rollout, not during UAT.

When to Consider This Package

Consider it when:

• The stack is already Laravel 13 + Livewire 4 + PHP 8.3+. This is a hard requirement, not a preference — it targets the newest major versions and will not help a Laravel 11/12 or Livewire 3 codebase.
• You need a first-party internal admin panel and can accept a pre-1.0, deliberately unstable API. v0.1.0 is explicitly "do not use in production."
• You want authorization, media handling, theming, menus, and a dashboard without stitching together four packages — the value is the bundle, not any single feature.
• You are comfortable installing from a VCS repository rather than Packagist, and pinning a commit or tag. Treat this as a vendored dependency under evaluation, not a normal Composer library.
• A timeboxed pilot in a non-critical internal tool is politically and technically feasible — this is the highest-value way to buy information before a real build-vs-buy commitment.

Look elsewhere (or wait) when:

• Production is the target now. The release note is unambiguous. Any roadmap item with an external SLA, payment flow, or regulated data should not sit behind a package whose API can change between patch releases.
• You need nested menus or drag-and-drop ordering. Up/down buttons only. If your information architecture is more than one level deep, this is a blocker, not an inconvenience.
• You require enterprise identity — SSO/SAML/OIDC, SCIM provisioning, granular audit trails. The permission tree is application-level RBAC; that is not the same thing as enterprise IAM.
• Supply-chain or procurement review applies. Not on Packagist, single GitHub organization, no stated support model, no versioning guarantees before 1.0. Some organizations cannot approve this today regardless of merit.
• Your team wants deep, bespoke admin UX. The data-driven/JSON-definition approach buys speed at the cost of control; heavy customization will fight the abstraction.
• You need upgrade-path confidence. UPGRADE.md exists for changes from earlier development builds, which tells you there have already been breaking changes inside the 0.x line. Budget for churn.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: Tardis is a pre-release Laravel admin panel that bundles the internal-tooling work we would otherwise build ourselves: CRUD screens generated from configuration, role-based access control, media management, menus, and a dashboard. The business case is cycle time — it plausibly removes weeks of undifferentiated scaffolding from internal tools. The counterweight is maturity: it is version 0.1.0, explicitly not production-ready, not yet on Packagist, and its API can still change. The recommendation is therefore a bounded pilot on one internal, low-risk tool with a pinned version, not an adoption decision. Success criteria: we ship that tool measurably faster, and we find no security or upgrade surprises.

To engineering — what to actually verify:

• Security review before anything else. The log viewer and command runner are the sensitive surface. Confirm the command runner is genuinely off by default, that the allow-list is server-side, and that log access is gated by the same access admin gate. Also review the install flow: tardis:install creates a super-admin and prints a generated password to the console — that output must not land in shared CI logs or terminal scrollback.
• The two sharp edges. (1) A required translatable field must be filled in every locale unless tardis.translation.validation is set to active. This is a content-entry UX trap that will generate support tickets; decide the setting deliberately. (2) php artisan route:cache must be re-run after creating a BREAD. That is a deploy-pipeline step, not a footnote — automate it or it will bite in staging.
• Version pinning and upgrade discipline. Install from VCS at a fixed tag or commit, document the pin, and treat UPGRADE.md as required reading on every bump. Do not float on ^0.1.
• Dependency-frontier risk. Laravel 13 and Livewire 4 are themselves new. Audit the rest of the dependency tree for packages that have not caught up — Tardis is only as adoptable as its stack.
• Extensibility check. The plugin system (assets, routes, settings screens) is the escape hatch for anything the BREAD abstraction does not cover. Spend an afternoon proving you can add one non-trivial screen through it before committing the pilot.

Bottom line for the decision log: approve a scoped pilot; do not approve production use. Revisit the assessment at 1.0, or when the package is on Packagist with a stated support and versioning policy — whichever comes first.