Platform Laravel Package

Product Decisions This Supports

• Build vs. buy for platform foundations. 0.4.0 bundles the undifferentiated scaffolding most products rebuild: authentication/registration, a user menu, page layouts, form theming, and now multi-tenancy. This is a "buy/build the chassis, build the product" decision rather than a feature-level one.
• Multi-tenancy as a roadmap fork. The new tenant isolation + access control work (PR #115) is the single most consequential item here: it decides whether you ship a single-tenant product now and retrofit isolation later, or launch with per-tenant data separation, tenant-scoped admin, and tiered/segmented customers from day one. Retrofitting tenancy is one of the most expensive migrations a SaaS can make — this materially de-risks the "start simple, go multi-tenant" path.
• Content authoring features. TextEditorType (Tiptap) unblocks a class of roadmap items that previously required a separate editor integration: CMS/marketing pages, knowledge base and help center, support macros, in-app announcements, rich email templates. Treat it as the enabler for a content surface, not a checkbox.
• Trust & safety / growth quality. Disposable-email blocking (with an auto-updated blocklist, now refreshing frequently) directly affects trial abuse, free-tier cost per signup, and the integrity of funnel metrics. This is a finance-and-growth decision as much as an engineering one.
• Back-office and internal tooling scope. Tabler page layouts, a KnpMenu-driven user dropdown, and a default form loading overlay are the "80% of an admin panel" that usually consumes a design and front-end sprint. Supports a decision to standardize internal tools on one shell instead of per-tool UIs.
• Platform upgrade runway. Symfony 8+ support plus a fully emptied PHPStan baseline signal an actively maintained, quality-gated upstream. Feeds the decision of whether to fork/extend versus consume as-is — a clean static-analysis baseline lowers the carrying cost of a fork.

When to Consider This Package

Adopt when:

• You are on Symfony, not Laravel. Despite framing, this release is unambiguously Symfony-shaped: Symfony 8+, KnpMenu, Twig, Webpack Encore, symfony/webpack-encore 7.x. On a Laravel codebase this is a reference architecture to borrow from, not a dependency to install — budget a port, or cherry-pick concepts (tenancy model, blocklist approach, editor form type).
• You want a maintained starter/foundation rather than a bespoke admin layer, and can accept an opinionated UI bundle (Tabler).
• Multi-tenancy with isolation and access control is on your 2–4 quarter horizon and you'd rather inherit it than design it.
• You have a named owner for dependency upgrades. At 0.4.0 you are pre-1.0: minors should be assumed to carry behavior changes.

Look elsewhere when:

• You require a stable public API or vendor LTS/support commitments. Pre-1.0 with this volume of toolchain movement is not that.
• You want a managed identity provider (Auth0, WorkOS, Clerk) and would rather not own registration, disposable-email policy, and blocklist rotation in-house.
• Your team cannot absorb a coordinated toolchain jump: Symfony 8, PHPUnit 13, Encore 7, Babel 8, jQuery 4, Tiptap 3, Rector 2.6, PHPStan 2.2.
• You need a headless/API-first core with UI strictly optional; the coupling to Twig, Encore, and a UI bundle is real.

Upgrade cautions before committing:

• Behavior change, on by default: the form loading overlay is now enabled for all forms (PR #180). Audit any form relying on custom submit handling, double-submit guards, or E2E assertions.
• Major front-end bumps: jQuery 3.7 → 4.0 is a breaking release; Tiptap 2 → 3, Babel 7 → 8, Encore 5 → 7 all carry migration cost. jQuery 4 in particular warrants a plugin/selector audit.
• Platform floor raised: Symfony 8+ means dropping older Symfony lines; verify your hosting and remaining dependency constraints first.
• user_menu contract: the dropdown is now driven by a user_menu KnpMenu (PR #178) — custom nav implementations need rewiring.
• Pin exact versions and read the changelog per minor; assume BC breaks until 1.0.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated solidworx/platform at its 0.4.0 release as a way to buy rather than build our platform's foundational layer — sign-up and auth, admin UI shell, and, most importantly, multi-tenancy with tenant isolation and access control, which is expensive to retrofit later. The release also adds a rich-text editor form type, disposable-email blocking with an automatically refreshed blocklist, and refreshed admin layouts. The upside is time-to-market and reduced headcount on non-differentiating work. The caveats are honest ones: it is pre-1.0 (expect breaking changes between minor versions), and it is a Symfony package — if our stack is Laravel, this is a design reference, not a dependency. Recommendation: pilot it against an internal back-office tool, and do not commit core domain logic to it before a 1.0.

For engineering leads:

• What we gain: multi-tenancy with isolation + access control (#115), TextEditorType on Tiptap (#121), disposable-email blocking with a CI-refreshed blocklist (#122 and recurring), Tabler page layouts (#176), KnpMenu user_menu (#178), loading overlay by default (#180), Symfony 8+ (#125), and a fully emptied PHPStan baseline (#126) — that last one is the strongest signal that forking is cheap to maintain.
• What it costs: a coordinated toolchain upgrade (Symfony 8, PHPUnit 13, Encore 7, Babel 8, jQuery 4, Tiptap 3, Rector 2.6) and one silent behavior change — the loading overlay is now on for every form, so check custom submit paths and browser tests.
• The ask: a timeboxed spike, pinned to 0.4.0, on a low-risk internal surface, with an explicit go/no-go on the 1.0 timeline.