Tall Mobile Laravel Package

Product Decisions This Supports

• Build vs. buy (or rather: build vs. scaffold) for the mobile web shell. Every mobile-facing Laravel product re-creates the same foundation: Tailwind breakpoints, an app-like layout, responsive navigation, modal and toast patterns. A TALL preset that encodes those conventions removes a recurring, undifferentiated task from the first sprint. The real decision is not "can we build a mobile-first layout" — we obviously can — but "do we want to keep re-deciding it on every project," and whether a preset is a better starting point than a blank laravel new.
• Roadmap commitment to "stay on TALL, go app-like." The package exists to make Livewire + Alpine + Tailwind feel like a mobile app rather than a web page. That is a strategic alternative to rebuilding the front end in React Native, Flutter, or a PWA framework. Adopting it — or at least adopting its patterns — is a vote for keeping one stack and one team, and it should be framed that way in roadmap reviews rather than as a UI dependency choice.
• Design-system consolidation. v1.0.1 relocated the modal directory into components, which is the standard Laravel convention for publishable Blade views. PM relevance: this is the difference between "each team copies a modal out of the last project" and "one predictable namespace everyone extends." It supports a stated goal of UI consistency across surfaces, not just tidiness.
• Upgrade-cost forecasting. That same relocation is a candidate breaking change for anyone who has published and edited the modal views — overrides at the old path won't be picked up. If we customise markup, budget a re-publish-and-reapply step; if we don't, it's a routine bump. Worth putting in the upgrade playbook now, because the package is archived and we will never get a migration guide from upstream.
• Vendor-risk tracking. Archived repository, ~1 star, single last release (2024-07-22), MIT. That combination means "no upstream support, no Laravel-version compatibility work, no security patches." This is a decision input, not a blocker: it disqualifies the package as a live production dependency and qualifies it as a fork/reference asset.
• Concrete use cases this unblocks: internal tools and admin-adjacent mobile flows, MVP and discovery-phase prototypes, demo builds for sales or stakeholder review, and design exploration where the goal is a clickable mobile shell in days rather than a component library in weeks.

When to Consider This Package

Consider it when:

• The product is an existing Laravel app already on Blade, Livewire, Alpine and Tailwind, and the gap is mobile-first layout and interaction conventions rather than missing features.
• You need a mobile shell fast — prototype, discovery build, demo, or an internal tool where time-to-first-screen dominates.
• You are willing to fork it and own it. MIT licensing, small surface area and a single-purpose scope make this cheap; the archive status makes it mandatory. Consume it as a starting template or vendored code, not as a Composer dependency you expect to upgrade.
• Someone can spend a short, bounded amount of time auditing it: Blade component names and view namespaces, publish tags, Tailwind config assumptions, Alpine interaction behaviour, focus management and ARIA for modals, and compatibility with the Laravel and Tailwind majors you actually run.
• You want its idioms more than its files — adopting the pattern (mobile-first components under a standard components namespace) and re-implementing in-house is a perfectly good outcome.

Look elsewhere when:

• This is a long-lived production product. Archived means no fixes for a future Laravel major, no Tailwind v4 compatibility work, no accessibility remediation, no security response. That is a standing liability, not a one-off risk.
• The front end is Inertia/React/Vue. A Blade-and-Livewire preset duplicates what the JS layer already does and will be discarded.
• You need a full design system: tokens, theming, dark mode guarantees, RTL/i18n, documented accessibility conformance. This is a preset, not a system, and treating it as one will disappoint the stakeholders you promised consistency to.
• You need semantic-versioning guarantees. A patch release that relocates a directory is normal for a young package, but it tells you the public surface is still settling — and with the repo archived, it has settled permanently at whatever v1.0.1 happens to be.
• Procurement, security or compliance review requires maintained dependencies with an SBOM and an upstream contact. There is effectively no upstream.
• You have no capacity to review the accessibility behaviour yourself. Do not outsource that review to an unmaintained package.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel starter preset for mobile-first interfaces — layouts, Tailwind conventions, and Alpine-powered interaction patterns, including a modal component that was reorganised in the most recent release. It is not a vendor platform and should not enter the dependency register as a strategic bet: the repository is archived, it has one star, and its last release was July 2024, so we should assume no future fixes or compatibility work. The value on offer is time, not capability: it can compress the mobile shell of a prototype or internal tool from weeks to days, and it gives us a reference implementation of the component conventions we want teams to share. Recommendation: treat it as a template we fork and own, funded from existing prototype budget, with no roadmap dependency and no expectation of upgrades. Cost is near zero and the downside is bounded to the cost of the fork.

For engineering: It's a TALL preset — Laravel, Livewire, Alpine, Tailwind — organised around mobile-first Blade and Livewire components. Read it as scaffolding, not as a library: fork it under our org, pin to a commit, and own the code. Two specifics before you start. First, v1.0.1 moved the modal views into a components directory — if you publish views, re-publish them and reapply any local edits rather than assuming overrides survived, and grep for old include paths and component tags if you're lifting code from an earlier snapshot. Second, verify it against our current Laravel and Tailwind versions before committing, because nothing upstream will do that for us. Wrap whatever you keep behind one internal component boundary so the origin is swappable, keep any published views in version control, and add a smoke test that actually opens and closes a modal — "view not found" and broken focus trapping are the failure modes you'd otherwise discover in production.