Default Laravel Package

Product Decisions This Supports

• Build vs. buy vs. assemble for the CMS layer. A default theme is the cheapest possible probe of whether Lavalite can produce a credible front end. If a demo-able site exists in days rather than weeks, that reframes the comparison against a bespoke Laravel build or a hosted CMS. The theme is the evidence, not the argument.
• Fork-and-own vs. design-from-scratch. litefront/default is the working reference implementation of Lavalite's theme contract — layout hierarchy, partial structure, view namespacing, asset publishing. Deciding to fork it or rebuild it is a scoping decision worth several days of estimate; this package is what makes that estimate concrete instead of theoretical.
• Roadmap sequencing for the first UI milestone. It lets you separate "we can show a page" from "we have a design system." Ship on the default theme to unblock stakeholder review and user testing, then treat the branded theme as a sized, tracked workstream rather than a launch blocker.
• Creating an internal starter theme as a deliverable. If the decision is fork-and-own, this becomes the seed of a first-party package — a resourcing and ownership question (who maintains it, how it is versioned) rather than a dependency question.
• A vendor-risk register entry with a cheap mitigation. Zero stars, zero dependents, zero score, and a typo in the package description are facts to record, not alarms. The mitigation — vendor the code, pin a commit, treat it as sample code — costs almost nothing.
• What it does not support: any differentiation, end-user capability, or revenue decision. It contributes presentation baseline only. Do not let it appear on a roadmap as value delivered.

When to Consider This Package

Consider it when:

• Lavalite/LiteFront is already chosen or on a short list, and you need a working front end this sprint.
• Your team needs to learn the theme package contract quickly — reading a functioning default theme is faster than reading documentation that may not exist.
• You intend to fork and own the code. Treat it as a template, never as a live dependency.
• You need a neutral, unbranded baseline for internal demos or client walkthroughs where visual polish is explicitly out of scope.

Look elsewhere when:

• You are not on Lavalite. With no stars and no dependents, there is no ecosystem reason to adopt a CMS because of this theme.
• You need a maintained design system with a patch cadence, accessibility guarantees, or a modern asset pipeline. A default theme is typically thin, Bootstrap-era scaffolding — verify what it actually ships (Vite? Tailwind? responsive breakpoints? a11y?) before assuming it clears your bar.
• You need multi-theme, white-label, or per-tenant branding. That is an evaluation of Lavalite's theming engine, not of one set of Blade files.
• Licensing, provenance, or ownership is unclear. At this signal level, assume no upstream support and confirm the license before anything touches production.
• A rebrand is on the roadmap within two quarters — forking now and rebranding later is usually more work than starting from your own layout.

Adoption checklist: license verified · code vendored or pinned to a commit SHA · one named owner · decision recorded explicitly as "fork" or "reference only."

How to Pitch It (Stakeholders)

To executives: This is a free starter kit, not a platform bet. It is the default look-and-feel shipped with the Lavalite CMS — the fastest route to a working screen, and it lets us defer design spend until the product thesis is validated. The maintenance risk is real but already understood and cheap to neutralize: we take a copy, own it, and never depend on the original being updated. Cost is roughly zero; benefit is measured in days removed from the first demo. Recommend approving it as scaffolding, with the explicit expectation that the branded theme remains a separately scoped, separately funded workstream. It delivers no customer-facing capability on its own.

To engineering: Treat litefront/default as reference code and a fork source, not a dependency. It encodes the theme contract — service provider registration, view namespace, layout and partial structure, published assets — so read it to understand the seam between CMS and presentation, then copy it into our repo rather than requiring it. Pin to a commit SHA, add a smoke test that renders each top-level view, and scan templates for unescaped output ({!! !!}), which is the usual smell in Laravel themes. Flag anything the theme assumes about the asset build — CDN links, a missing build step, inline scripts — since that is where the hidden cost lives in default themes. Validate in this order: PHP and illuminate/* constraints, then Lavalite core compatibility, then the service provider contract against our Laravel version. Failures at the first two are hard stops, not patch targets — a theme is never worth a platform downgrade. Verify the license before the first commit.

To design: This is a wireframe with opinions. Expect generic typography, stock spacing, and no component library. Use it to pressure-test information architecture, navigation, and content hierarchy — not to negotiate visual direction. That conversation should happen against our own theme package, and the sooner we say so out loud, the less rework we do.