Founder Laravel Package

Technical Evaluation

Architecture fit. Founder is not a runtime package — it is an opinionated Laravel application starter template, consumed via composer create-project or a repo fork. It therefore fits exactly one scenario: greenfield Laravel services that want a pre-wired baseline (auth scaffolding, user/RBAC, admin surface, testing and CI conventions). It does not fit existing applications, and it cannot be composer required into an established codebase. The value is entirely front-loaded scaffolding, not ongoing library capability.

Integration feasibility. High for a greenfield prototype, low for anything production-critical in an existing estate. Because it is a template, adoption means inheriting every architectural decision the maintainer made (auth strategy, permission model, directory layout, test harness, container setup) and then owning them. Cherry-picking individual patterns (role/permission wiring, admin scaffolding) into an existing app is possible but manual and undocumented.

Technical risk. Material, and asymmetric:

• Staleness: last release 2022-06-05 places it around the Laravel 9 era. Current Laravel majors are several versions ahead; the template's dependencies, auth approach, and scaffolding will need immediate upgrading (laravel-shift or manual) before first use.
• Adoption signal: 47 stars and effectively no downstream usage means near-zero community validation, thin issue history, and little evidence of security review. This is a reference implementation, not a battle-tested baseline.
• Bus factor of one. The maintainer's personal starter is the entire support surface.
• Hidden coupling: "starter" projects bake in opinions that are cheap to start and expensive to unwind (e.g., RBAC data model, user impersonation, admin routes).

Key questions.

1. Which Laravel and PHP versions does the pinned composer.json target, and what is the upgrade delta to the current LTS?
2. Which auth stack does it assume (Breeze / Jetstream / Fortify / hand-rolled), and does that align with our identity provider requirements?
3. What permission model is scaffolded (e.g., Spatie laravel-permission, gates/policies) and does it fit our tenancy model?
4. Is it MIT-licensed, and are we comfortable forking and owning it?
5. Does upstream show any activity post-2022, or is this effectively archived?
6. What does it include for CI, static analysis, containerization, and secret management — and is any of it usable as-is?

Integration Approach

Stack fit. Laravel/PHP shops only. If the target service is Laravel, the conventions are internally coherent and reduce day-one setup. If the target is Symfony, Node, or a polyglot platform, it is irrelevant.

Migration path. There is no migration path from an existing app — the only honest paths are:

• Adopt as baseline: fork into an internal, org-named template repo (platform/laravel-baseline), pin dependencies, run an immediate Laravel upgrade, and treat the fork as v0.1 of our own standard. Upstream becomes historical reference only.
• Reference only: read the layout and auth/role wiring, extract patterns, leave the repo out of the build. This is the low-risk default given the adoption/staleness signals.

Compatibility. Verify against our supported Laravel and PHP matrix before committing. Expect to bump the framework, replace stale transitive dependencies, and reconcile any generated config with our secrets management and environment conventions. Any "compatibility" claim should be validated by running the template's own test suite after upgrade.

Sequencing.

1. Spike: create-project locally, run tests, upgrade to current Laravel, time-box a day.
2. Decide adopt-vs-reference on evidence from the spike (upgrade effort, opinion conflicts).
3. If adopting: fork, strip unused opinionated surfaces (impersonation, admin routes we won't use), wire to our CI, SCA, and image pipeline.
4. Establish an internal owner and a documented "diff from upstream" policy before the second team uses it.
5. Retire the upstream remote or archive it; do not attempt to track a dormant maintainer.

Operational Impact

Maintenance. Ownership transfers entirely to us on fork. There is no upstream to lean on for Laravel upgrades or security patches; every future framework major is our cost. This is the dominant operational expense and should be budgeted as such — a starter template saves days at kickoff and adds an ongoing maintenance line item.

Support. Community-only, single maintainer, dormant since 2022. No commercial support, thin documentation, minimal issue history. Do not place a team behind this without an internal owner.

Scaling. The template itself imposes no runtime scaling constraints — it is ordinary Laravel. The scaling risk is organizational: opinionated auth and RBAC choices are easy to duplicate across teams and hard to converge later. Mitigate by standardizing the fork centrally rather than letting squads clone ad hoc.

Failure modes.

• Abandoned upstream with no security patching — transitively inherited CVEs.
• Breaking Laravel upgrades discovered late because the template pinned old majors.
• Divergent forks across teams ("starter drift") producing snowflake apps.
• Silent coupling to the maintainer's assumptions that surface as rework at the first non-trivial auth requirement.
• Licensing ambiguity if the fork's provenance isn't recorded (confirm MIT and preserve notices).

Ramp-up. Moderate. The code follows Laravel conventions, so any Laravel developer is productive quickly, but the template-specific opinions (role model, test layout, admin wiring) are undocumented at this star count and must be reverse-engineered. Budget onboarding notes as part of the fork, not after.

Recommendation (TPM). Treat Founder as a reference architecture, not a dependency. Given the 2022 staleness, minimal adoption, and single-maintainer bus factor, the defensible move is a short spike to harvest patterns, followed — if we want an internal baseline — by a fork we own, upgrade, and document. Do not adopt it as the sanctioned starting point for production services without that ownership commitment.