Statamic Butik Laravel Package

Technical Evaluation

Initial assessment for jonassiewertsen/statamic-butik v4.0.0-beta.1. This is a Statamic e-commerce addon for Laravel/PHP applications. The release is significant because it adds Statamic 4 support and Laravel 9/10 support, but it is a beta and a major-version release, so it should be treated as an evaluation candidate rather than a production default.

Architecture fit: Fits Laravel applications already using Statamic as the content/control-plane CMS and needing commerce capabilities inside the same stack. The addon model is a reasonable fit where content, storefront, and lightweight commerce workflows should remain coupled in one Laravel runtime. It is less attractive where commerce requires independent scaling, strict PCI boundaries, or enterprise order-management isolation.

Integration feasibility: Feasible via Composer, Statamic addon registration, publishable config/views/migrations, and Laravel routing/middleware conventions. Laravel 9/10 plus Statamic 4 support removes a major compatibility blocker for modern stacks. Actual feasibility depends on custom Statamic fieldset/blueprint compatibility, payment/shipping integrations, queue/webhook behavior, and whether v3 customizations survive v4 changes.

Technical risk: Medium-high for v4.0.0-beta.1. Major-version beta implies possible breaking changes, incomplete migration documentation, dependency constraint churn, and limited production hardening. Statamic 4/Laravel 9/10 support is positive, but the release notes do not state backward-compatibility guarantees, PHP version support, database migration impact, or payment-gateway compatibility.

Key questions: What are the exact breaking changes from v3.6.1? Is there an upgrade guide and data migration path? Which PHP/Laravel/Statamic matrix is tested in CI? Are payment webhooks, order state transitions, tax/shipping rules, and multi-site/localization supported? What is the v3 support/EOL policy? Are there production references for v4 beta? What is the rollback plan if checkout or order data migration fails?

Integration Approach

Stack fit: Best fit is a Laravel 9/10 application on Statamic 4, with PHP versions confirmed against the package’s Composer constraints. Avoid adopting v4 beta on a stack still on Statamic 3 or older Laravel unless the upgrade is explicitly part of the initiative.

Migration path: Keep current production on v3.6.1 or the last proven stable release. Create an isolated upgrade branch for Statamic 4/Laravel 9/10 and v4.0.0-beta.1. Run database migrations and content-model checks in staging with representative product, order, customer, tax, shipping, and payment data. Do not combine framework upgrade, addon upgrade, and checkout customization changes in one production release.

Compatibility: Validate Composer dependency resolution, addon service provider registration, published config, views/templates, routes, middleware, event listeners, queue jobs, and webhook endpoints. Verify custom fields, blueprints, order statuses, cart persistence, payment gateway callbacks, and any overwritten views. Confirm that existing database tables and order history remain readable.

Sequencing: 1) Inventory current Butik customizations and integration points. 2) Upgrade Laravel/Statamic in staging. 3) Install v4 beta with pinned versions. 4) Run migrations and content/field checks. 5) Execute checkout, order lifecycle, refund, webhook, and admin regression tests. 6) Run a limited pilot or canary. 7) Promote only after rollback and data-restore paths are proven.

Operational Impact

Maintenance: Expect active monitoring during beta. Pin the exact beta/stable version, watch upstream changelog and issue tracker, and budget for follow-up releases before v4 stabilizes. Maintain a fork/patch strategy only if checkout-critical defects appear.

Support: Likely community/maintainer-led support rather than an enterprise SLA. Internal ownership must cover Statamic, Laravel, payment integrations, and order-data integrity. Document escalation paths for checkout and payment failures.

Scaling: Inherits Laravel/Statamic scaling characteristics. Commerce workloads may stress order writes, checkout sessions, webhook handling, and admin reporting more than CMS reads. Use queue workers, caching, database indexes, and idempotent webhook processing. Validate behavior under peak checkout load and multi-site traffic.

Failure modes: Beta incompatibility with Statamic 4 or Laravel 10; broken checkout or payment callbacks; lost or duplicated orders; failed migrations; overwritten views/config; dependency conflicts; unhandled webhook retries; and degraded admin order management. Each needs monitoring, alerts, and a rollback runbook.

Ramp-up: Moderate for a team already fluent in Laravel and Statamic; higher for teams without Statamic addon or e-commerce operations experience. Ramp-up should include addon architecture, order lifecycle, payment/webhook flows, deployment/migration procedure, and incident response.