Tomato Breeze Laravel Package

Product Decisions This Supports

• Build vs. buy — more accurately, build vs. fork — for the auth and app-shell layer. This package is a scaffold, not a runtime dependency. It replaces roughly two to three sprint-weeks of design, frontend, and QA work (login, registration, logout, password reset, email verification, profile, layout, navigation, theme toggle) with an install-and-rebrand pass. Every new Laravel app in the portfolio faces this same decision, so treat it as a reusable template decision rather than a one-off evaluation.

• RTL-first market entry. The differentiating feature is not the Breeze scaffolding — Laravel ships that free — it's first-class RTL and dark mode out of the box. If the roadmap touches Arabic, Hebrew, or Persian markets, or an admin surface that gets demoed dark-themed to executives, this lets us validate that UX now instead of parking it in a localization phase that never gets funded. This is the single strongest reason to look at the package at all.

• Frontend stack standardization. Adopting this is a decision to adopt Splade (Blade-rendered Vue 3 — no Inertia, no Livewire), by stealth if we're not explicit about it. If Splade is already our standard, this makes that standard concrete and consistent across the TomatoPHP/Filament-adjacent ecosystem. If it isn't, this is a stack review, not a utility pickup — and it should go through the same gate as any other framework choice.

• Speed-over-longevity bets. A good fit for internal back-office dashboards, admin apps, MVPs, hackathon and POC builds, and stakeholder demos where time-to-visible beats time-to-durable. A poor fit for long-lived, externally audited, customer-facing products where authentication is a compliance surface with an auditor attached to it.

• Vendor-risk triage on existing codebases. For any team already running this — or discovered quietly running it — the forced decision is "fork and own, or migrate off." Given 0 stars, 0 dependents, and a last release of April 2023, the answer is fork-and-own: commit the generated code as first-party, tag the upstream commit, drop the runtime requirement, and register the fork as self-maintained.

• Portfolio-level upgrade budgeting. Starter kits don't upgrade, they get re-scaffolded. Adopting it creates a recurring line item — roughly 2–4 engineer-days per Laravel major version — that has to appear in planning, not surface as a surprise mid-quarter.

When to Consider This Package

Consider it — as a fork, not a dependency — when:

• Splade is already your frontend standard, or you are prepared to make it one. Otherwise the RTL/dark payoff is buried under a stack migration nobody budgeted for.
• RTL and dark mode are v1 requirements, not aspirational roadmap items. Stock Laravel Breeze gives you neither.
• The project is internal, short-horizon, or low-blast-radius, and you can name an owner for the auth screens from day one. An unowned auth fork is how password-reset flows rot.
• You're inside or adjacent to the TomatoPHP ecosystem and want admin and UI conventions to match sibling packages.
• You only want the RTL/dark Tailwind layer. It's an extractable slice — the Tailwind config changes, the CSS variable/theme layer, and the layout's dir/class handling — liftable onto existing Breeze views in one to two days, capturing most of the real value without adopting Splade.

Look elsewhere when:

• You need ongoing upstream security patching. Last release was April 2023, on authentication scaffolding — precisely the surface where stale templates are least acceptable. It predates Laravel 11's slimmed skeleton and Breeze's own restructure; assume a Laravel 9/10 + PHP 8.1/8.2 target until a throwaway-app spike proves otherwise. A Laravel 11/12 port is 3–5 engineer-days; if it exceeds ~5, take only the RTL/dark CSS layer and hand-build the rest.
• You already run tomato-admin (Filament). Two auth front ends, two theming systems, two upgrade tracks, and a confused web.php. That's an architectural collision, not an integration task — decide which paradigm owns authentication before introducing the second one.
• You already ship first-party laravel/breeze. Namespace and route-name collisions, duplicated routes/auth.php, and a Tailwind config fighting itself. Pick one.
• You need a community to lean on. Zero stars means zero Stack Overflow answers; every edge case is discovered by reading the source. Budget for that, and factor it into the fork-and-own posture rather than treating it as a footnote.
• The team can't absorb a "pin everything and commit the lock" discipline. Splade, Tailwind, Vue, and the Prologue PHP packages all move independently. An unpinned composer update against auth scaffolding we don't control is how a Friday goes bad.

How to Pitch It (Stakeholders)

To executives: "We can stand up a complete, branded login and account experience — including right-to-left layouts for Arabic-market expansion and dark mode for demos — in days instead of weeks. The cost is that we own the code afterward, so we're budgeting a small recurring maintenance line rather than an ongoing license or vendor contract. Best suited to internal tools and demos, not to audited customer-facing products."

To engineering: "This is a scaffold, not a library. We install it in a throwaway app first to confirm the stack, run the five core flows — register, verify, log in, edit profile, reset password — in both LTR and RTL and both themes, then publish everything into our own namespace, commit it, and drop the Composer dependency. From that point it's our code: one-owner, feature-tested on those four flows, with the upstream commit tagged so we can diff against Laravel Breeze security fixes issued since April 2023. Budget 2–4 engineer-days per Laravel major to re-port, and treat RTL regressions as a manual visual checklist item since they won't fail CI."

The one-line decision framing: if Splade plus RTL plus dark mode are all genuinely required in v1, this saves real time and is worth the fork. If any one of the three is negotiable, stock Breeze plus a small theme layer is the cheaper, lower-risk path — and this package's honest value reduces to about a day and a half of Tailwind work.