Mary Laravel Package

Product Decisions This Supports

• Build vs. buy for the UI layer. maryUI is effectively a pre-built component library (inputs, tables, modals, toasts, datepickers, charts-adjacent widgets, file upload, editor, calendar) delivered as Blade/Livewire components on daisyUI + Tailwind. The decision it collapses is: "do we spend 4–8 engineer-weeks building an internal design system, or adopt one and spend that time on domain logic?" For back-office surfaces the answer is usually adopt.
• Roadmap sequencing. Because components are drop-in Blade tags, it moves UI work off the critical path. A PM can commit to a demo-able admin surface in the first sprint instead of a design-system milestone, which lets you pull forward discovery on higher-value features.
• Scope of the internal-tools portfolio. Packages like this make marginal internal surfaces economically viable — a support console, an ops back office, a customer-config screen that would never justify a bespoke front end now costs days, not weeks. That changes which internal bets get funded at all.
• Stack and hiring constraints. It lets a PHP-centric team ship interactive, good-looking UI without a dedicated front-end hire or a JS SPA. That is a real org-shape decision: it keeps the team single-stack and reduces handoff overhead.
• Consistency spend. Adopting one component source for all admin surfaces retires the "every screen looks like a different product" tax without a design-system program. DaisyUI themes give you light/dark and brand-token control cheaply.
• Use cases it serves well: internal dashboards and admin panels, SaaS back offices, CRUD-heavy operational tooling, MVPs and design partners' pilots, client portals inside a Laravel monolith, rapid prototypes for stakeholder validation.
• Key product risk to price in: this is a single-maintainer project with a large community PR pipeline and a very high patch cadence (2.9.x shipping several small fixes weekly). That's a velocity signal, but also a churn signal. Treat upgrades as a recurring line item, not a one-time adoption.

When to Consider This Package

Adopt when most of these are true:

• The product runs Laravel + Livewire 3 + Tailwind and you intend to stay there for the planning horizon.
• The surface is internal, back-office, or authenticated — where "conventional and consistent" beats "brand-defining."
• Your team is PHP-first, with limited or no dedicated front-end capacity.
• You can pin the version and schedule periodic dependency upgrades (monthly cadence is realistic).
• You're comfortable with Blade component coupling — i.e., your templates will carry <x-…> tags from a third party, and ripping it out later means touching every template.
• You accept daisyUI's aesthetic and theming model rather than owning a design language.
• Legal is fine with MIT-in-practice but NOASSERTION-declared licensing on the package, and with TinyMCE under GPL/commercial terms if you use the Editor component in a commercial product. That last one is the single most likely adoption blocker; scope it out or license it deliberately.

Look elsewhere when:

• You're on React/Vue/Svelte, or your Livewire usage is incidental. There's no value here.
• The surface is public-facing, brand-critical, or conversion-optimized — you'll fight the defaults more than you save.
• You need a design system you own (multi-product, multi-team, design-token governance, Figma parity).
• Accessibility is a contract requirement. Components are improving (focus traps, RTL, keyboard nav landing in recent releases) but this is community-paced, not an audited a11y program.
• You need SLAs, indemnification, or a support contract. Single-maintainer, sponsor-funded. Have a plan for "maintainer steps away" — forking is the realistic hedge and should be a pre-approved option, not a scramble.
• Version churn is unacceptable (regulated, long-lived, rarely-touched codebases). Note the 2.3.0 release shipped a rename (enabled → hidden on menu components) inside a minor version — treat semver here as directional, not contractual.
• You need heavy bespoke interaction (complex drag-drop canvases, rich data viz, real-time collaborative UI). You'll be writing it yourself anyway.
• Packagist dependent counts are unreliable here (reported as 0). Don't use that as a health signal in either direction; assess the commit/PR velocity and issue responsiveness directly.

How to Pitch It (Stakeholders)

To executives — one paragraph: maryUI is a mature, actively maintained open-source UI component library for our existing Laravel/Livewire stack (~1.5k GitHub stars, weekly release cadence, MIT-licensed). Adopting it converts internal admin and back-office UI from a multi-week engineering project into a configuration exercise, letting the team spend that capacity on product logic and customer-facing features. Cost is essentially zero in licensing and low in integration; the principal risks are maintenance concentration (one primary maintainer, community-supported) and upgrade churn, both mitigated by version pinning, a monthly dependency-upgrade habit, and a pre-agreed fork contingency. Recommendation: adopt for internal and authenticated surfaces; keep it off brand-critical public pages; require legal sign-off on the optional rich-text editor component before use.

To engineering — the honest version:

• It's a Blade component layer, not a framework. Low conceptual load, no new runtime, no build-tool changes beyond daisyUI in your Tailwind config.
• Pin the version in composer.json and review changelogs on upgrade. Recent releases are mostly one-line fixes to specific components (drawer IDs, tab badges, menu horizontals, gallery CSS), which means low-risk patches but frequent rebasing if you track @dev.
• Known footguns: breaking renames have shipped in minor versions; the Editor component wraps TinyMCE and carries GPL/commercial licensing implications; Tailwind/daisyUI major-version moves will gate your upgrade path.
• Contingency: because components are Blade templates you can vendor the package (repositories.local path install is documented) and fork if maintenance stalls. Budget that as a real, small option — not a hypothetical.

The ask: a two-week spike on one internal surface to measure actual time-to-ship against a hand-rolled baseline, plus legal review of the licensing posture, before committing the broader tooling portfolio to it.