Mary Ui Starter Kit Laravel Package

Product Decisions This Supports

• Greenfield internal tooling vs. custom build: This scaffold materially shortens time-to-first-screen for admin panels, back-office CRUD, and small SaaS consoles. For a PM weighing "build the shell ourselves" against "seed from a template," the honest comparison is roughly 1–3 weeks of UI/auth/layout boilerplate vs. days of customization — a real but bounded saving, not a strategic one.
• Frontend architecture commitment (the biggest lever): Adopting this is a decision to standardize on Laravel + Livewire + Blade + Tailwind/daisyUI. That is a multi-quarter hiring, tooling, and design-system commitment. PMs should treat this as an architecture decision record, not a package selection.
• Roadmap sequencing: Best used as the seed for a low-stakes internal tool used to validate developer experience and deployment before it becomes the house template. Fund one pilot, gate standardization on its outcome.
• Build vs. buy vs. fork: This is neither buy nor a dependency — it's a one-time fork with no supported upgrade channel. Decide and state the ownership model (internal owner named) up front; retrofitting ownership later is the expensive path.
• Buyer/user-facing scope: Poor fit for public-facing, SEO-critical, or heavily client-stateful surfaces. This constrains which roadmap items the scaffold can serve — do not let a prototype on this stack become the de facto answer for a marketing site or a high-interactivity consumer app.
• Vendor/risk posture: Single-maintainer, 5 stars, MIT, community-only support, and a patch release (v1.0.2) with no narrative changelog. This is a cost-saving template, not a strategic partnership — no roadmap dependency should be placed on upstream delivering anything.

When to Consider This Package

Consider it when:

• The project is greenfield internal tooling — admin consoles, back-office CRUD, ops dashboards — where speed to a working screen dominates architectural purity.
• The team is already fluent in Laravel and Blade and has Livewire familiarity or appetite (days to productivity vs. one to two sprints for Livewire newcomers).
• You want pre-styled auth + app layouts + reusable form/table/card components and have no existing design-system mandate that conflicts.
• You can accept fork-and-own: pin the exact tag, record the provenance commit, name an internal owner, and budget for dependency churn yourself.
• You're running a bounded pilot to evaluate the stack before standardizing.

Look elsewhere when:

• The surface is customer-facing, regulated, or uptime-critical — no SLA, community-only support, and generated auth flows require security review rather than trust.
• The team is standardized on Inertia/React/Vue, or the work is API-only.
• You need a long-term vendor relationship or a supported upgrade path between versions.
• You're brownfield: integration feasibility here is near-zero. Cherry-pick components and config rather than retrofitting.
• Scale expectations exceed tens to low hundreds of concurrent internal users without profiling Livewire round-trip latency and memory.

Mandatory pre-commitment gates: classify the v1.0.2 diff (cosmetic vs. dependency bump vs. behavioral), confirm pinned Laravel/PHP/Livewire/Tailwind versions against the platform baseline, and review generated auth, authorization, and seeders.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a free, MIT-licensed Laravel starter kit that gives us a pre-built, professionally styled admin application shell — authentication, layouts, forms, and tables — so engineering starts on our actual business logic instead of rebuilding boilerplate. The realistic saving is one to three weeks of setup on internal tools. The trade-off is clear and manageable: we own the code from day one, there is no vendor contract or support SLA, and it is maintained by a single individual. It is a sensible accelerator for internal back-office software, not a foundation for customer-facing products, and we recommend a single low-stakes pilot before making it our standard template.

For engineering — the honest version: Treat this as a one-time seed, not a dependency. Pin v1.0.2 in the create-project command, record the provenance commit in the README, and delete the upstream remote so nobody attempts painful merges. Verify the v1.0.2 diff first — there's no changelog body, only a compare link — and confirm Laravel, Livewire, and Tailwind majors against our baseline. Two known traps: Tailwind's content array must include MaryUI's component path or every component renders unstyled, and Livewire major versions must be paired with MaryUI's supported range. Review the generated auth and roles before trusting them. Then build one internal tool end to end and report on developer experience and deployment.

For design/product — what it means in practice: We get a themed, dark-mode-capable component library (MaryUI on daisyUI/Tailwind) with a small set of stock themes and a documented path to a custom brand theme in tailwind.config.js. Styling changes are cheap; component behavior changes are not. Expect a coherent, slightly opinionated internal-tool aesthetic rather than a bespoke design system — and budget accordingly if the brand bar is higher than that.