Ui Builder Laravel Package

Product Decisions This Supports

• Build vs. buy for UI/form primitives: The package now provides class-based UI components (UiComponent, formerly HtmlComponent) plus attribute-setting methods and corrected form labels. This supports buying reusable form/UI scaffolding instead of maintaining a bespoke component layer, especially for internal tools, admin panels, and CRUD-heavy workflows.
• Roadmap sequencing: Treat v0.15.0 as an API evolution release, not a drop-in upgrade. The HtmlComponent → UiComponent rename is a breaking change: schedule migration work before adopting the new minor, and avoid starting new feature work against the old class name.
• Scope reduction: New attribute-setting methods reduce the need for one-off wrapper components and custom markup helpers. Product can defer or cut “component flexibility” work from the roadmap and redirect effort to user-facing features.
• Quality and accessibility: The form-label fix lowers the risk of mislabeled inputs, reduces QA/support noise, and supports accessibility and form-usability requirements without custom remediation.
• Release risk management: Because the package is still pre-1.0, treat each minor as potentially breaking. Pin versions, require an upgrade ticket per bump, and avoid betting a customer-facing surface on it without a migration budget.

When to Consider This Package

Consider adoption when:

• The product is a Laravel application with recurring form, admin, or internal-tool UI needs.
• The team wants reusable component primitives without building and maintaining its own library.
• You can absorb pre-1.0 API churn, including class renames and minor-version breaking changes.
• You have a low-risk pilot surface and a clear owner for upgrades.
• You value faster delivery of forms and labels over long-term API stability.

Look elsewhere when:

• The UI is a highly bespoke design system where package components would be overridden heavily.
• The surface is customer-critical and requires stable, long-term-supported APIs with formal deprecation cycles.
• The team cannot budget refactoring time for renames such as HtmlComponent → UiComponent.
• Strict accessibility certification or design-system governance requires vendor-backed guarantees.
• You need semantic-versioning discipline and the package remains on 0.x.

How to Pitch It (Stakeholders)

For executives: This package can shorten delivery time for internal tools and form-heavy screens by providing ready-made UI and form components. The latest release adds flexibility and fixes form labels, which improves quality and reduces rework. The main caveat is maturity: it is pre-1.0, and v0.15.0 includes a breaking class rename. Recommend a contained pilot and a small upgrade budget rather than a platform-wide commitment.

For engineering: v0.15.0 renames HtmlComponent to UiComponent, adds attribute-setting methods, and fixes form labels. The rename requires a refactor, so pin the current version, schedule migration, and avoid mixing old and new class names. The attribute API should reduce custom wrapper code; the label fix improves form correctness. Adopt behind a clear upgrade policy until a 1.0 release provides API stability.