Civicrm Core Laravel Package

Technical Evaluation

Architecture fit

• civicrm/civicrm-core is not a Laravel package and should not be scoped as one in a roadmap. There is no ServiceProvider, no facade, no publishable config, no container bindings. It ships its own bootstrap (CRM_Core_Config), DAO layer (CRM_Core_DAO), entity metadata, ACL system, and API layers (APIv3 legacy, APIv4 current).
• The correct architectural framing for planning purposes is peer service, not dependency: CiviCRM is the CRM system of record for contacts, relationships, contributions, memberships, events, cases, groups and custom fields; the Laravel application remains the owner of product UX, auth, billing and its own domain.
• CiviCRM expects a CMS host (Drupal, WordPress, Joomla, Backdrop) or its Standalone bootstrap to supply routing, identity and session. Laravel cannot play that role without bespoke, unmaintained glue. Any estimate that assumes embedding is wrong at the root.
• Consequence for roadmap: this is a buy-vs-build decision on a domain, not an "add a library" decision. That framing belongs in the PRD, not the tech design doc.

Integration feasibility

• The supported seam is APIv4 over REST (/civicrm/ajax/api4/{Entity}/{action}), plus webhooks/civicrm_post hooks and the cv CLI for provisioning and scripted ops.
• composer require civicrm/civicrm-core inside a Laravel app is unsupported — the repo's composer.json serves its own dev/CI tooling. A "successful" install still needs civicrm.settings.php, filesystem paths, a CMS host, and a database installer run. Correcting this premise is the single highest-value thing a TPM can do before estimation.
• Authentication is a real spike item, not a build-time detail: legacy API key + site key, or the authx extension for JWT/OAuth-style flows. It determines whether the Laravel client is a service account or a per-user delegated model — a security and audit decision.
• Zero Packagist dependents is expected, not disqualifying. It measures composer consumers; applications aren't consumed that way. Development happens on GitLab (lab.civicrm.org); GitHub is effectively a mirror. Adoption must be validated through the extension ecosystem and community channels, not repo metrics.

Technical risk

• AGPL-3.0 is the top-severity risk and it is a product risk, not just legal. Network copyleft means modifying CiviCRM and exposing it over a network likely obligates offering corresponding source. Pure API consumption from Laravel is generally safe; linking, patching, bundling, or forking is not automatically safe. This gates pricing and packaging (self-hosted services vs. closed SaaS) and should be settled before engineering commits.
• Front-end debt with a shelf life. AngularJS is EOL; upstream is moving to SearchKit/FormBuilder/Afform. Contributor guidance shows active lint/idiom curation (ang/, Karma specs, lodash avoidance, esversion: 11). Any UI-adjacent customisation has a defined obsolescence horizon.
• Mid-migration API surface. Guidance pushes new work to APIv4 and off crmApi/APIv3. That implies a long, uneven tail we would be operating through — budget for it rather than assume a clean contract.
• Heavy local dev and CI. Karma shells out to cv and needs an installed site on PATH; PHPUnit needs a provisioned database. Pipelines are slow and onboarding is non-trivial.
• Governance is a positive signal with an obligation. AI-agent involvement must be declared in commits/PRs ("an agent bears no responsibility for its output"). Upstreaming is viable and preferable to a private patch set — but our contribution policy must match theirs.
• Read the scores correctly. Overall 28.95 against opportunity 45.04 is not a quality signal; it's the package-ecosystem lens misfiring on an application. Treat the gap as "market demand exists," not "adoption proven."

Key questions

1. Is the Laravel framing genuine (embed a CRM in a Laravel app) or a misread of the package? If genuine, is a lighter CRM or a Laravel-native package the better fit?
2. Which CMS host, and who owns it operationally — us, or an implementation partner?
3. Is the product closed-source SaaS? If yes, has counsel reviewed AGPL network-use exposure and the boundary around our Laravel code?
4. Can we commit to pure API consumer + extensions only, or does the roadmap depend on patching core?
5. Multi-tenant requirement? CiviCRM is single-site-per-install; multi-tenancy means N installs and N upgrade paths — a direct cost multiplier.
6. Who owns the upgrade cadence, and is there budget for a partner support contract or is community-only acceptable?

Integration Approach

Stack fit

• Laravel = orchestration and product layer. CiviCRM = CRM engine. Laravel owns UX, auth, billing, jobs; CiviCRM owns contacts, activities, relationships, contributions, groups, custom fields, dedupe rules.
• Build a CrmClient adapter interface in Laravel with a CiviCRM implementation behind it. This is the only real hedge against AGPL and upgrade risk, and it lets tests stub the CRM instead of provisioning one.
• Do not share a database. CiviCRM owns a civicrm_-prefixed schema with views, triggers and its own migration cadence. Cross-system SQL reads are a latent outage, not a shortcut.
• Webhooks/civicrm_post require a small in-CMS extension we own — scope it as a first-class deliverable with its own maintenance line, not a script.

Migration path

• Phase 0 — spike (1–2 weeks): stand up CiviCRM on WordPress or Drupal in a container; prove APIv4 read/write with authx tokens; validate the API surface for the top 5 entities; confirm PHP version parity. Go/no-go on data-model fit, extension cost vs. build cost, and AGPL compatibility.
• Phase 1 — read-only: contact/activity/group reads into Laravel; establish a stable external_identifier convention and map to contact_id.
• Phase 2 — single-direction writes (Laravel → CiviCRM) for one entity, with idempotency keys and a dead-letter queue.
• Phase 3 — decommission any CRM tables currently in Laravel: scripted, re-runnable importer; dual-read reconciliation before cutover.
• Phase 4 — event-driven bidirectional sync via webhooks plus a nightly drift-reconciliation job.

Compatibility

• PHP version parity is a hard gate. CiviCRM's supported PHP range lags Laravel's floor (Laravel 11 requires 8.2+). Pin the CiviCRM release line first, then choose the Laravel version — never the reverse.
• MySQL/MariaDB only. No PostgreSQL. Verify the CMS host's DB expectations align with CiviCRM's before committing the environment.
• Treat the CiviCRM release line as a fixed external dependency in the plan; its cadence sets our upgrade window.

Sequencing

• Run the legal read on AGPL in parallel with the spike, not after. A fail there invalidates the whole build, and late discovery is the expensive version.
• Feature-flag the integration so read-only and write paths can ship independently.
• Land the adapter interface before the first write path, or the CRM will leak into controllers and the exit option disappears.

Operational Impact

Maintenance

• Upgrading CiviCRM is an external release cadence we don't control and must be scheduled like a vendor upgrade: read the release notes on GitLab, test extensions, run DB upgrades via cv, verify the API surface we depend on.
• Adopt extensions, never fork core. A fork is a permanent maintenance tax and an AGPL problem simultaneously. Budget the extension layer as a standing line item.
• APIv3→APIv4 migration means some documented patterns we inherit will be deprecated on arrival. Prefer APIv4 exclusively and expect to rewrite any community example we copy.
• Front-end customisations sitting on AngularJS carry an expiry date. Plan to move to SearchKit/FormBuilder/Afform or to avoid UI work entirely and keep our own UX in Laravel.

Support

• Community model gives partners, not warranties: no SLA, no indemnification, no named vendor. If those are non-negotiable (public-sector or enterprise procurement), a paid partner contract must be in the budget or the option is off the table.
• We own the operational runbook: cron/job.execute, mail queue, payment processor reconciliation, dedupe rule tuning.
• Upstream contribution is viable and encouraged — but require the AI-agent declaration in our own contribution policy so agent-assisted patches can be sent upstream without friction.

Scaling

• Single-site per install. Multi-tenancy = N installs, N upgrades, N backup/restore paths. This is the largest hidden cost multiplier and should be quantified per tenant in the business case.
• Form-and-batch-oriented PHP application, not a headless API platform. High-throughput, low-latency API requirements are a poor fit; design batch sync and caching rather than assuming request-per-interaction.
• CiviMail deliverability (domain reputation, throttling, bounce handling) is an operational specialty, not a checkbox — often underestimated in nonprofit deployments.
• Database is the usual bottleneck; plan for read replicas/reporting offload before contact volume gets large.

Failure modes

• AGPL breach discovered post-launch — remediation cost exceeds the entire integration.
• PHP version deadlock between the CMS host, CiviCRM and Laravel, discovered at upgrade time.
• Cross-database reads silently breaking when CiviCRM migrates its schema.
• Dedupe conflicts on bidirectional sync creating duplicate contacts and misattributed contributions — a data-integrity event, not a bug.
• Lost webhooks without a reconciliation job produce silent drift in financial records.
• Extension abandonment leaving a required capability unmaintained across an upgrade.
• UI customisation rot as AngularJS surfaces are replaced upstream.

Ramp-up

• Requires PHP depth in-house or a partner — both a CiviCRM domain modeller (entities, custom fields, price sets, ACLs, dedupe rules) and someone fluent in cv, the extension scaffold and civicrm.settings.php.
• The Laravel-side work is ordinary API-client engineering; the CiviCRM-side learning curve is the schedule risk.
• Onboarding includes GitLab (lab.civicrm.org) as the real home of issues and discussion; GitHub familiarity is misleading.
• Recommend two engineering weeks for the spike plus a legal read, with a formal decision at the end: adopt, adopt-with-extension-layer, or build.