Ti Theme Toolkit Laravel Package

Product Decisions This Supports

Build vs. buy for the theme foundation. Every TastyIgniter theme we ship re-implements the same commodity layer: a service provider wiring views/lang/Livewire/routes, a settings schema, a color system, asset build config, dark mode. This package is the "buy" option for that commodity layer (MIT, forkable). The PM decision it informs: is theme plumbing a differentiator or a cost center? If it's a cost center — and it almost always is — standardizing on a shared toolkit is the correct call, and this package is a ready-made candidate.

Theme-family / vertical-skin roadmap. The headline claim — "ship a custom theme in under 50 lines of PHP" — is a velocity claim you can plan against. It makes a roadmap of multiple skins per year (per vertical: pizzeria, café, ghost-kitchen, fine-dining) economically plausible instead of one bespoke theme per year. Each incremental theme inherits auth, contact, newsletter, dark mode, and the customizer without re-building them.

White-label and brand-customization packaging. ColorHelper + ThemePayloadResolver derive an entire primary palette from a single admin-picked color. That is a product decision, not a technical one: it lets you sell "your brand colors, self-serve" from the admin customizer instead of selling custom development hours. It also opens a multi-tenant/multi-brand tier where one codebase serves N brand palettes.

Self-serve merchandising and compliance surface. BaseSchema defines a 7-tab customizer (general, banners, colors, dark mode, social, advanced, GDPR) and BannerManager gives merchants a hero-banner widget. This directly supports decisions about onboarding cost, support-ticket volume, and whether GDPR/consent configuration ships by default (de-risking EU launch and cutting per-theme legal review).

Feature-parity policy across the theme portfolio. Shared Livewire components (Login, Register, ResetPassword, Socialite, Contact, NewsletterSubscribeForm) plus shared form classes mean every theme gets the same auth and capture flows for free, and themes can override any component by path. That settles per-theme scope debates: those flows are baseline, not per-theme negotiation.

Consolidation / tech-debt initiative. If we currently run N divergent theme forks, migrating them onto one toolkit is a measurable maintenance-reduction program: PRs per theme, duplicated code deleted, shared bug fixes landing once.

Reliability and brand-trust items. Auto-publishing assets on theme activation (0.4.0) removes a class of "missing favicon / broken logo after install" incidents; scoped storefront error views (0.5.0, fixed for multi-theme in 0.6.2) mean branded 404/500 pages resolve correctly per active theme. These are small but real support-cost and brand-consistency levers.

What it does not inform: pricing, checkout, ordering, or menu logic. This is presentation and theme infrastructure only — do not let it creep into the commerce roadmap.

When to Consider This Package

Adopt when:

• You are on TastyIgniter 4.0+, PHP 8.2+, Livewire 3, Tailwind, Vite 5, Alpine 3. These are hard prerequisites, not nice-to-haves.
• You are building or maintaining two or more themes, or expect to within a year. The abstraction cost is only repaid across multiple themes.
• You want a design-token system with dark mode and an admin color customizer without inventing one — the CSS-variable → Tailwind-mapped → inline <html style> data flow is already designed and documented.
• Your team is comfortable with the Tailwind/Vite/TypeScript toolchain, or willing to accept preset-driven config. The package ships hand-written .d.ts files so themes can run strict: true end-to-end — a genuine quality signal.
• You can pin exact versions and absorb churn. The changelog shows real API movement inside 0.x: a changed loadLivewireComponentsFrom() signature, tailwind-preset.js removed, tokens.css replaced by theme.css, new namespace defaults via reflection. Budget for upgrade work each minor.
• You are willing to fork. MIT + a small surface area makes forking practical. Given zero stars, zero dependents, and a single maintainer, assume you may become the maintainer.

Look elsewhere / deprioritize when:

• You're shipping one bespoke theme for one restaurant. The abstraction tax exceeds the savings; a plain TastyIgniter theme is simpler.
• You're not on TastyIgniter. Only the patterns (palette derivation, schema merging) are portable; the code is not.
• You need stability guarantees — a 1.0 API, an LTS window, a security-response commitment, or a vendor SLA. Nothing here provides that, and the absence of dependents means no downstream battle-testing.
• The design is heavily art-directed per page. Token-driven systems push toward consistency; if brand requires page-by-page divergence, you'll fight the conventions.
• You can't carry upstream workaround debt. The package already ships a corrective listener for tastyigniter/ti-ext-pages#21 marked TODO: remove once merged. That's responsible engineering, but it's debt you inherit.
• Diligence flag before committing: the README lists Tailwind 3.0+ while changelog 0.3.0 migrates to Tailwind v4 and removes the Tailwind preset. Resolve this against your actual toolchain before adoption — treat the README as possibly stale and the changelog as authoritative.

Minimum diligence checklist: confirm the Tailwind major version you'll target; run the 12-test Pest suite plus a testbench smoke test against your PHP/TI versions; verify the multi-theme error-view scoping fix (0.6.2) with two toolkit themes installed simultaneously; confirm asset auto-publish on activation works in your hosting/deploy model.

How to Pitch It (Stakeholders)

Executive summary. TiPowerUp Theme Toolkit is an MIT-licensed PHP + frontend foundation that lets us build restaurant storefront themes on a shared base instead of rebuilding common infrastructure each time. It consolidates the service provider, admin settings schema, color/design-token system, dark mode, asset pipeline, and customer-facing flows (login, registration, password reset, social sign-in, contact, newsletter) into one maintained layer. The expected business effect is straightforward: lower engineering hours per theme launch, consistent branding and dark-mode behavior across the portfolio, and self-serve brand/color customization for merchants instead of billable custom work. It is a small, self-contained dependency with no licensing cost and essentially no lock-in — MIT, forkable, and confined to the presentation layer. The trade-off is maturity: it is pre-1.0, has a single maintainer and no external adopters, so we should adopt it as an internal standard with a named owner, pin exact versions, and hold a fork option rather than treat it as a supported vendor product.

For engineering. You get a documented base service provider (AbstractThemeServiceProvider) that wires views, translations, Livewire components, Blade components, routing, and theme data; a 7-tab field schema with a merge() helper instead of hand-rolled settings arrays; a color system that derives a full palette from one primary color and renders it as CSS custom properties; an Alpine dark-mode store with localStorage persistence; and Vite/Tailwind presets that auto-detect app.ts over app.js. Livewire business logic is single-source and overridable by path, so themes own views, not behavior. TypeScript declarations ship as hand-written .d.ts files — no build step, strict-mode clean. The ask: one sprint to migrate a pilot theme, then compare hours-to-launch and duplicated-code volume against the previous theme. Constraints to plan around: pin exact 0.x versions, expect breaking changes in minor bumps, and do not let toolkit types leak into business logic — keep it behind a thin boundary so a fork stays cheap.

For product and design. Design tokens, derived palettes, and dark mode ship as defaults, so a new theme starts visually coherent rather than blank. The 7-tab customizer (colors, banners, dark mode, social, advanced, GDPR) is a merchant-facing settings surface we can demo and price against, and BannerManager gives non-technical merchants direct control of hero slides. Treat the color customizer and dark mode as growth levers we can test per brand, not just plumbing.

Risks and mitigations, stated plainly. Pre-1.0 API; one maintainer; zero external adopters; documented upstream workarounds. Mitigations: pin versions, assign an internal owner, keep the fork option funded and trivial to exercise, and validate the Tailwind v3-vs-v4 documentation discrepancy during the pilot. Recommended decision: adopt for the theme portfolio, scoped to the pilot, with a go/no-go review on measured hours-to-launch after the first migrated theme.