Ti Theme Orange Laravel Package

Product Decisions This Supports

• Build vs. buy at the storefront layer. Orange gives you a production-ready, responsive restaurant storefront (menu browsing, AJAX add-to-cart, single- or two-page checkout, reservations) on TastyIgniter. The decision this package settles is "do we build our own front-end theme, or start from a vendor-maintained one?" — and it makes starting from a theme the clearly cheaper path.
• Time-to-first-orderable-storefront. Replaces weeks of menu/cart/checkout scaffolding with a configurable theme. Directly supports a roadmap milestone like "restaurant ordering live for pilot merchants" rather than a generic "build a website" goal.
• Merchant self-service / customization scope. The Theme Editor (securityRedirectPage, layout and appearance options) is a product lever: decide which customizations merchants can do themselves (branding, checkout flow, page content) versus which require engineering. This bounds your support and professional-services cost per merchant.
• Fork-vs-extend decision. Because it is Blade + Livewire, the realistic product decision is "fork Orange as our house theme, or consume it as an upstream dependency." That choice determines your upgrade tax and your ability to differentiate on checkout UX.
• Checkout funnel experimentation. Single- vs. two-page checkout is a theme-level option, so A/B tests on checkout length, ordering flow, and tip handling are configuration, not re-architecture. Supports conversion-rate OKRs with low engineering spend.
• Feature sequencing for adjacent bets. Delivery-area validation, fulfillment scheduling (ASAP/later), delivery-address pinning ("Mark Your Location"), reviews/ratings, and newsletter capture all exist today. That means roadmap items like loyalty, multi-location, or delivery-radius expansion are net-new work, not a prerequisite rebuild.
• Security/compliance posture as a roadmap input. The v4.3.0 timing-attack fix on forgot-password and the v4.1.6 XSS escaping fix show that customer-facing security surface (auth enumeration, output escaping) ships through the theme. That is a standing operational commitment you must budget for, not a one-off task.
• Use cases in scope: restaurant, café, bar, bistro, pizza, bakery, and food-delivery operators on TastyIgniter — including single-location pilots where the theme's default IA is acceptable without brand redesign.

When to Consider This Package

Consider it when:

• You are already committed to TastyIgniter (or actively evaluating it as your ordering platform). Outside that stack, the package has essentially no reusable value — it assumes core models and components (LocationData, Booking, CartBox, OrderPreview, Livewire cart and checkout flows) that do not exist elsewhere.
• You need a functional ordering storefront quickly and the default information architecture (menu, cart, checkout, reservations) matches your merchants' needs.
• You want Livewire + Bootstrap 5 + Blade as your front-end stack, with no SPA/front-end framework mandate.
• You are comfortable forking an MIT-licensed theme and owning a merge cadence against upstream releases.
• You can absorb front-end-layer behavior changes as functional releases — the changelog shows checkout validation, order-total persistence, tip handling, and fulfillment scheduling restrictions all changing in patch/minor theme versions. Plan regression testing on the purchase funnel for every upgrade.

Look elsewhere when:

• You are not on TastyIgniter. The coupling is pervasive, not adapter-shaped.
• You need a differentiated brand experience at launch. The theme is a starting point; a bespoke design system means forking and largely rewriting templates.
• You need front-end stack independence (React/Vue/Next storefront, headless/API-first ordering). Orange presupposes Blade-rendered Livewire components.
• You need vendor-backed SLAs or commercial support. MIT plus a 6-star, 0-dependent footprint signals a small ecosystem; the "dependents: 0" figure is a poor adoption proxy for a first-party theme, but it does mean you should expect to self-serve on integration questions and rely on the core repo's issue tracker rather than this repo's.
• Your product surface is broader than restaurant ordering (retail, grocery with complex substitutions, marketplace/multi-vendor). The domain assumptions will fight you.
• You can't tolerate a fast-moving upstream. Releases land frequently with real behavior changes; teams with heavy release-gating or long QA cycles will feel the churn.

How to Pitch It (Stakeholders)

For executives: Orange is a free (MIT), actively maintained, first-party storefront theme for TastyIgniter that gets a restaurant online-ordering experience — menu, cart, checkout, reservations, reviews, delivery-address handling — to market in a fraction of the time of a custom build. It is responsive, mobile-first, SEO-extension compatible, and configurable by merchants through a Theme Editor, which reduces per-merchant setup cost and support load. The trade: it is not a standalone asset. Its value is entirely realized inside TastyIgniter, and it carries an ongoing maintenance obligation because customer-facing security and checkout logic ship through theme releases (e.g., a recent email-enumeration fix and an XSS escaping fix). Recommendation: adopt as the base theme, fork it, and treat upstream releases as functional upgrades requiring checkout regression testing — not as cosmetic version bumps.

For engineering: Blade + Livewire 3.7+ + Bootstrap 5. Template overrides are straightforward; the theme is readable and explicitly built for customization. Two things to internalize before committing: (1) presentation and domain logic are interleaved — checkout validation, order-total persistence, fulfillment scheduling restrictions, and cart state live in Livewire components inside the theme, so an "upgrade the theme" ticket is a behavior-change ticket; (2) the coupling to TastyIgniter core models is deep and not abstracted, so treat the fork as your product surface and pin/merge upstream deliberately rather than floating on latest. Budget for a documented merge playbook, a funnel regression suite (cart → checkout → payment → order totals), and ownership of the fork.

Risks to name out loud: small public adoption signal (6 stars, 0 dependents) despite first-party status; frequent release cadence with real behavior changes; no commercial support path; and a hard dependency on continuing investment in TastyIgniter itself.