Coilpack Laravel Package

Product Decisions This Supports

• Replatform vs. rebuild, and how fast. Coilpack lets a Laravel application read ExpressionEngine content (entries, channels, categories, members) through Eloquent-style models and render EE templates from a Laravel app. That makes an incremental "strangler fig" migration viable: ship a new Laravel front end, keep EE as the system of record for editorial content, and move routes over one at a time instead of committing to a single big-bang content migration.
• Build vs. buy on the CMS layer. Rather than evaluating a new CMS license, the decision becomes "do we keep paying for EE and build our product features in Laravel, or do we migrate content and drop EE?" Coilpack is the enabler for the first option and gives you a defensible cost comparison against a full migration project.
• Roadmap sequencing. If the content model is stable and the product roadmap is about member portals, subscriptions, APIs, or app-layer features (the things Laravel is good at), this package decouples those from the CMS question. It lets product work start this quarter while the content strategy is decided later.
• Use cases worth scoping: agency or in-house sites with a long-lived EE install and trained editors; member/subscription portals needing real auth, queues, and background jobs; exposing existing EE entries as a content API for a mobile app or new channel; A/B or parallel-run of a redesigned front end against the same editorial source.
• A "no" decision this supports too. If the roadmap is to exit EE within two quarters, a one-time export script is cheaper than adopting and then retiring a bridge. Coilpack's value is proportional to how long you intend to keep EE alive.

When to Consider This Package

Adopt when:

• You already own an ExpressionEngine license and have editors actively publishing in it; the content investment is real and expensive to recreate.
• You need Laravel capabilities — queues, jobs, events, auth, packages, Pest/PHPUnit testing, modern deployment — that EE alone doesn't give you.
• A full content migration is off the table for at least 9–12 months on cost, risk, or editorial change-management grounds.
• You have PHP/Laravel depth in-house and can absorb a low-adoption dependency. Treat it as code you may end up owning.
• The integration surface is narrow: read-mostly content access, template rendering, and routing. You are not depending on it for complex EE add-on behavior.

Look elsewhere when:

• Greenfield. With no existing EE content, this is pure overhead. Use Laravel with a Laravel-native CMS (e.g., Statamic) or a headless CMS instead.
• You need vendor support or an SLA. 28 GitHub stars and a single-maintainer-shaped footprint mean thin documentation, limited Stack Overflow coverage, and no commercial backing. Budget for reading the source and potentially forking.
• Your EE usage is deeply add-on dependent. Third-party fieldtypes, complex template logic, and add-on-driven behavior are where bridge layers typically leak.
• EE is on the way out. If the honest plan is to leave within a year, the bridge is a bridge to nowhere.
• You need write-back parity. Assume read-oriented integration until proven otherwise; editorial writes, publish workflows, and cache invalidation need explicit validation in a spike.

Practical adoption gate: run a one-week spike against a real EE database — a content listing page, a detail page, and one authenticated route — before committing. Pin the version, confirm it against your EE major version, and check the release cadence (last release Nov 2025 is a positive signal on maintenance).

How to Pitch It (Stakeholders)

For executives (the business case): We have a substantial investment in ExpressionEngine content and editorial workflow. This package lets us keep that investment and still build new product features on Laravel, the framework our engineering team is fastest in. The alternative — a full content migration — is a multi-month project with real editorial disruption and no customer-visible benefit. Coilpack turns a risky all-at-once replatform into a series of small, reversible steps, so we can ship customer-facing improvements sooner and stop work at any point without stranding content. It's MIT-licensed, so there's no new licensing cost beyond the EE license we already carry. The trade-off is a period of running two systems and a dependency on a small open-source project, which we mitigate by pinning versions and budgeting for in-house ownership.

For engineering (the technical case): It's a Composer package that maps EE's database into Eloquent-style models and lets Laravel render EE templates and resolve routes, so we can adopt it route-by-route rather than all at once. It fits standard Laravel testing and deployment practices, and the code is small enough to read, patch, or fork if needed. The honest caveats: expect read-heavy integration, verify coverage against our specific add-ons and fieldtypes, and validate cache invalidation and member/auth boundaries in a spike before we size the work. Low community adoption means we should treat the maintainer's release cadence as a risk input and avoid making it load-bearing for anything we can't replace.