Appshell Laravel Package

Technical Evaluation

Architecture fit. konekt/appshell is not a library you call — it is an application skeleton you inhabit. It ships opinionated base Eloquent models (User/Admin), ACL wiring, migrations, seeders, Blade layouts, and assumes its sibling ecosystem (konekt/concord for modularity, Konekt's ACL and address packages) is present. That makes it a strong fit for exactly one shape: a server-rendered, modular-monolith Laravel business app (internal tooling, CRM/ERP-lite, back-office portals) built greenfield by a team willing to adopt Konekt's conventions wholesale. It is a poor fit for API-first services, SPA/Inertia/Livewire-first frontends, or any codebase that already has its own identity and authorization model. The coupling is structural, not incidental: your User table, guards, policies, and admin UI all inherit from the package.

Integration feasibility. Mechanically simple — composer require, service-provider discovery, publish migrations and config, extend the base models. Strategically expensive. Retrofitting AppShell into an existing application means replacing the user table, reconciling auth guards, and rewriting policies; it is effectively a re-platforming exercise disguised as a dependency. Greenfield adoption is a day-one decision, not a later one.

Technical risk. High, and driven by adoption signals rather than code quality. 83 stars and zero recorded dependents means almost no public production footprint to learn from, noStack Overflow corpus, and no third-party tutorials. The package appears to be primarily maintained to support the vendor's own products — a bus factor of one. Documentation is example-driven and thin; the supported Laravel/PHP matrix must be verified against your target version rather than assumed. The MIT license is permissive and the code is forkable, which mitigates abandonment risk but converts it into ownership cost.

Key questions.

• Which Laravel and PHP majors are supported today, and what is the maintainer's stated upgrade cadence?
• Does it hard-require konekt/concord, or can the model/migration layer be used standalone?
• What is the ACL model — role-based, permission-based, team/tenant-scoped — and is there a documented CVE/security-disclosure path?
• Is there a maintained reference application or demo repo demonstrating a real deployment?
• What is the test coverage and CI matrix for the identity and authorization paths specifically?

Integration Approach

Stack fit. Laravel + Blade + a Bootstrap-lineage admin theme. Assume it will dictate your auth scaffolding and admin chrome. It will collide with Breeze/Jetstream/Filament and with spatie/laravel-permission — pick one authorization model, not two. If the product roadmap includes a mobile client or public API, plan for Sanctum/Passport alongside, and expect the package's session-oriented assumptions to need bridging.

Migration path. Greenfield only. For brownfield, the defensible move is pattern harvesting: read the package for its module structure, base-model conventions, and ACL schema, then implement equivalents natively. Importing it into a live app is a multi-sprint migration with a user-table cutover — fund it as such or decline it.

Compatibility. Verify Concord's module bootstrap against Laravel's package discovery order; module service providers loading after cached config is a classic failure. Check transitive dependency pins (doctrine/dbal, Symfony components) against your other packages before committing.

Sequencing.

1. Timeboxed spike on a throwaway branch — install, publish, build one CRUD resource end-to-end, measure friction.
2. Pin exact versions and commit the lockfile; treat upgrades as planned work, not composer update.
3. Fork to an internal namespace on day one. Vendoring is not pessimism here; it is the realistic steady state.
4. Insert a thin adapter layer around User and ACL so the underlying implementation stays replaceable.
5. Write integration tests for login, role assignment, and tenant isolation before feature work begins.

Operational Impact

Maintenance. Budget for ownership. Expect to carry the fork, cherry-pick upstream when convenient, and track security patches for transitive dependencies yourself. Upstream release cadence is likely tied to the vendor's product needs, not yours.

Support. GitHub issues and maintainer goodwill. No SLA, no commercial support tier, no documented security process. Escalation paths do not exist; plan accordingly for anything customer-facing or regulated.

Scaling. Adequate for internal-scale workloads — thousands of users, standard CRUD throughput. Two pressure points: ACL checks can add per-request query overhead (cache resolved permissions per session), and multi-tenant isolation correctness lives partly in the package, where a defect is a data-breach-class incident rather than a bug. Test tenant boundaries explicitly and independently of the package's own suite.

Failure modes. A Laravel major release lands and the package constraint blocks your upgrade; migration collisions on shared tables; silent behavioral changes in base models after a minor bump; admin UI breakage on asset/theme updates; fork drift until you can no longer merge upstream at all. Each is recoverable, none is cheap.

Ramp-up. Two to four weeks for a Laravel-fluent engineer to be productive, longer for anyone unfamiliar with Concord's module conventions — the patterns are nonstandard and poorly documented externally. Exit cost is the real concern: once every model extends the package's base classes, replacing it is a quarter-scale project. Treat that as a known, accepted liability before adoption, not a discovery after.