Lattice Laravel Package

Product Decisions This Supports

• Feature delivery: back-office and internal tooling. Lattice lets PHP define the UI — tables, forms, layouts, actions — and React render it. For CRUD-heavy surfaces (admin consoles, ops tooling, settings, approval queues, catalogue management), the UI becomes a byproduct of server code, so a PM can schedule UI changes inside a backend sprint instead of queueing behind frontend capacity.
• Roadmap sequencing: decouple UI iteration from release cadence. Because presentation is server-defined, copy changes, new columns, extra fields, and workflow tweaks ship with a normal deploy — no client release gate and no app-store review. That changes what you can credibly promise about "we'll refine it after launch."
• Build vs. buy vs. framework. Internal tooling has three lanes: hand-built Inertia/React pages, an admin framework (Filament/Nova), or a generic tool builder (Retool). Lattice is the middle path — Laravel-native and code-first like the first two, but with a declarative, schema-driven UI contract like the third. Choose it when you want admin-framework velocity without adopting that ecosystem's opinionated resource model, and you want React as the render layer rather than Blade/Livewire.
• Interaction consistency as an explicit product decision. Actions return a typed result that fans out into toasts, callouts, redirects, modal open/close, form reset, and targeted component reloads. That is a ready-made UX vocabulary: you can standardize ("every destructive action confirms; every mutation toasts; only the affected table reloads") and get consistency by default rather than negotiating it per screen.
• Estimability. The declarative contract makes "add a filter," "add a bulk action," "add a confirmation step" small, composable, predictable units. Useful for turning vague stakeholder requests into quotable scope.
• Gating and personalization. Server-defined UI means the server decides what a user sees. The action layer already ships authorization hooks and subject-ability checks, which is real leverage for role-, plan-, or permission-tiered surfaces without branching a frontend build.
• What it explicitly does not support: public-facing, brand-differentiated, or motion-heavy UI. Keep that on a separate track.

When to Consider This Package

Adopt when most of these hold:

• Stack fit. Laravel backend plus a React frontend already in place (Inertia-style, server-owned routing and props). Without both, this is a rewrite, not a dependency.
• Workload shape. The roadmap is dominated by tables, forms, filters, CRUD, bulk operations, and modals — the large, unglamorous majority of internal product surface area.
• Team shape. PHP-strong, frontend-constrained. Two React engineers and one Laravel engineer is the wrong trade; the inverse is a good one.
• Speed over pixel control. You accept the framework's component vocabulary and layout primitives instead of a bespoke design system.
• You can carry maturity risk. 62 stars, zero dependents, no visible third-party production validation, and a composite score well below the level where I would call adoption proven. Verify release cadence, open-issue responsiveness, and maintainer count yourself before committing — the published release date looks anomalous and should not be taken at face value.

Look elsewhere when:

• The UI is the product. Consumer apps, marketing sites, SEO-critical pages, or anything where design differentiation, custom animation, and pixel-level control are competitive requirements.
• You need vendor accountability. No commercial support, no SLA, no escalation path. If the project stalls you own the fork — MIT makes that legally trivial and practically expensive.
• You need deep client-side interactivity — offline, real-time collaboration, canvas, complex local state. Server round-trips are the wrong primitive.
• You need accessibility sign-off you can evidence. A young component set almost certainly does not come with an audited a11y story; you would be inheriting that risk.
• An admin framework already covers you. If Filament or Nova handles 90% of the need, adding a second, less-proven abstraction for the remaining 10% is a bad trade.
• You cannot absorb the abstraction cost. Debugging crosses PHP → serialization → React. Onboarding now means teaching a proprietary DSL on top of React and Laravel idioms.

How to Pitch It (Stakeholders)

One line: a Laravel package that lets us build internal UI — tables, forms, actions — in PHP and have React render it, so product changes ship without a frontend ticket.

For executives: the business case is throughput, not technology. The surfaces that consume the most engineering time — admin, ops, settings, approval workflows — are exactly what this handles, so changes there stop competing with customer-facing work for frontend capacity. That is a cheaper route to the same backlog. The cost side is stated plainly: this is early-stage open source with minimal adoption, so we are trading maintenance risk for velocity. Cap that exposure with a timeboxed pilot on a non-critical surface before any broader commitment, and keep the exit cheap.

For engineering: Lattice replaces hand-written Inertia pages with declarative definitions — components, tables, forms, actions — evaluated server-side and rendered by a React tree. It brings a typed action/effect contract (mutations return toasts, redirects, modals, scoped component reloads), signed action context so per-record identifiers cannot be tampered with, first-class authorization hooks, bulk operations over table selections, and closure-based evaluation for computed fields and dependent inputs. It is MIT and Laravel-idiomatic, so the escape hatch is genuine: any surface can be reimplemented as a plain Inertia page without leaving the stack.

Recommendation: run a two-to-four week spike on one bounded internal surface, behind a feature flag, with a named owner. Agree success criteria up front: time-to-ship for a representative UI change versus baseline, no regression on action-heavy flows, and a straight answer to "can we debug this at 2am?" If the spike does not clearly beat the baseline, stop — the sunk cost is weeks, not an architecture.