Web Installer Laravel Package

Product Decisions This Supports

• Build vs. buy for onboarding: shipu/web-installer provides a browser-driven setup wizard for Laravel apps (environment checks, database credentials, .env generation, migrations, first admin user). This directly supports the decision to ship a self-hosted/distributable product without building and maintaining an install flow in-house — a multi-week engineering cost compressed into a dependency.
• Go-to-market for self-hosted and licensed distribution: if the roadmap includes selling or distributing the application to customers who deploy on their own infrastructure (marketplace scripts, white-label installs, on-prem enterprise pilots), a guided installer is a prerequisite. It converts "read the README and edit .env" into a supportable, repeatable funnel.
• Activation and time-to-first-value: the installer is the first product surface a self-hosting customer touches. Reducing installation failure is the cheapest activation improvement available — it removes the most common cause of pre-sales tickets ("500 error on first run", "database connection refused").
• Support-cost and CS-capacity planning: an installer absorbs a category of tier-1 support load. This informs headcount and documentation investment decisions.
• Production readiness of the deployment path: v1.0.1 fixes config:cache errors caused by closures in the package config — closures make the entire config uncacheable. Since php artisan config:cache is a standard step in essentially every Laravel production deploy pipeline, v1.0.0 could break the deployment of any app that adopted it. This release is what makes the package viable for a production pipeline at all, and it should be the minimum version pinned in any evaluation or composer constraint.

When to Consider This Package

Consider it when:

• You ship a Laravel application to customers who must install it themselves and cannot be asked to run artisan commands or hand-edit .env.
• Your product is sold or licensed per-instance (CodeCanyon-style distribution, on-prem, agency handoffs) and onboarding friction is a conversion or refund problem.
• You want an installer surface now, with a small dependency footprint, rather than owning the flow. Building this in-house is only justified if you need deep customization (multi-tenant provisioning, licensing checks, hosted control panel integration).
• You are on v1.0.1 or later. Do not adopt v1.0.0 — the config:cache defect will surface in staging or production, not in local development, which is the worst place to find it.

Look elsewhere or build in-house when:

• You operate a managed SaaS where you control deployment — the installer is dead weight and adds attack surface.
• You require hardened, audited install flows. An installer writes .env, executes migrations, and creates an admin account; it must be disabled or removed post-install and its routes protected. This package is early-stage (v1.0.x, single maintainer plus one new contributor), and a defect class as fundamental as "closures in config break caching" suggests limited testing against real production deployment workflows. Validate it against your own CI/deploy pipeline before committing.
• You need multi-step licensing, payment gating, or upgrade/migration wizards — that is application logic, not installer logic, and the overlap will be small.
• Your stack is not Laravel or your Laravel version is outside the package's supported range.

Diligence items before adoption: confirm the installer routes can be locked down or removed after setup, verify idempotency if the wizard is re-run, and re-run your full deploy (including config:cache and route:cache) with the package installed.

How to Pitch It (Stakeholders)

For executives: We can ship a self-service installation experience for customers who host the product themselves without spending engineering time building one. That shortens time-to-first-value, reduces the pre-sales and onboarding support burden, and removes a blocker to any self-hosted or per-license distribution model on the roadmap. The cost is a small, low-commitment dependency.

For engineering: It's a Laravel package that supplies the setup wizard — environment checks, DB configuration, .env writing, migrations, admin creation. Pin v1.0.1 minimum: v1.0.0 embedded closures in its config, which makes php artisan config:cache fail and would have broken production deploys while passing locally. v1.0.1 resolves that, with no breaking changes, no new features, and no migration work. Budget a short spike, not a project: verify the flow end-to-end in a production-like deploy, confirm the installer routes can be disabled or removed post-install, and check re-run behavior. It is early-stage software, so treat it as a dependency we validate rather than one we assume is hardened.

Recommendation: Adopt for evaluation now on v1.0.1; gate broader rollout on a passing production deploy check and a documented post-install lockdown step.