Appmanager Laravel Package

Technical Evaluation

Architecture fit. This release materially narrows the package’s identity: hulkapps/appmanager is not a generic Laravel module registry — it is a Shopify app billing/plans/discount orchestration SDK tied to HulkApps’ App Manager backend. Release 3.7.0 adds promotional-discount targeting, automatic discounts, per-plan discount injection into /plans, an /automatic-discount endpoint, and charge-path application in ChargeController::process(). That fits a Shopify app already using App Manager for plans and billing. It does not fit a general Laravel modular monolith unless that app is also a Shopify app on App Manager. The key architectural dependency is now explicit: the SDK requires App Manager with promotional-discount targeting (MGR-97) deployed.

Integration feasibility. Composer-installable and MIT-licensed, so source review and forking remain viable. But integration is no longer just “boot the service provider and see what registers.” The package now spans the billing display path and the actual charge path, which means correctness must be verified end-to-end: /plans, automatic-discount resolution, priority tie-breaking, “upgrades only” behavior, and fail-safe behavior. The release notes say no configuration or fail-safe schema change is required, but the data semantics change: discount_code, shop_installed_at, automatic-discount flags, priority, per-plan value/type/cycles, and current-plan comparison all matter. A one-to-two-day spike is probably still enough for source review and a sandbox boot; it is not enough to validate revenue-path behavior.

Technical risk. High, and now concentrated in billing correctness rather than only provenance. The fail-safe design intentionally withholds automatic and targeted discounts during an App Manager outage — they are neither shown nor charged — while plain coded discounts still fail-safe as before. That is conservative from a charging standpoint but creates a visible merchant-facing behavior: eligible discounts disappear during outages. Priority resolution and “automatic breaks a tie” need deterministic tests. “Upgrades only” requires reliable current-plan comparison. The package also introduces a hard runtime dependency on a specific App Manager deployment (MGR-97), so version skew between SDK and backend is a real failure mode. Provenance remains weak: single vendor, no apparent downstream community validation, and no independent support surface.

Key questions for the vendor/repo author:

• Is MGR-97 deployed and version-pinned in every environment (dev, staging, production)?
• What is the exact API contract for /plans and /automatic-discount, and how are errors surfaced?
• Does ChargeController::process() replace or extend our existing billing controller? What is the extension model?
• How is discount priority configured, and what happens when automatic and coded discounts tie or conflict?
• How is “upgrades only” determined — current plan lookup, cached state, or merchant payload?
• What data must the app provide for discount_code and shop_installed_at, and what happens when either is missing?
• Does the package publish routes (/plans, /automatic-discount) that can collide with existing endpoints?
• Does it hard-depend on a specific Shopify SDK or other HulkApps packages?
• Is there a CI matrix for supported Laravel/PHP versions, and is the release reproducible from tags?

Integration Approach

Stack fit. Adopt only if we are running a Shopify app on HulkApps App Manager and want App Manager-managed promotional discounts. If we are not on App Manager, or if billing/plans are first-party, this package is not a fit. Treat it as a revenue-path SDK, not a utility.

Migration path. Keep an anti-corruption layer around billing and discount resolution. Define first-party contracts for plan pricing, discount eligibility, and charge application, then implement them with a thin adapter over the SDK. Domain code should not import HulkApps\... namespaces directly. If the SDK owns or expects specific discount fields, mirror those semantics into our schema and billing documentation on day one, even though the release notes say no schema change is required. Feature-flag the new promotional-discount behavior and compare display/charge parity against current billing before broad rollout.

Compatibility. Verify route and controller collisions for /plans and /automatic-discount, and confirm whether ChargeController::process() is bound into our billing flow or must be subclassed. Validate the Laravel/PHP floor, Shopify SDK compatibility, and transitive dependencies with composer why and composer audit. Most importantly, confirm backend compatibility with MGR-97 in each environment; SDK/backend version skew is now a first-class integration risk.

Sequencing.

1. Source review, dependency audit, and confirmation that MGR-97 is deployed in the target environment.
2. Sandbox Shopify app on a development store: boot, configure, exercise /plans, automatic discount, coded discount, and combined priority cases.
3. Contract tests for discount resolution: automatic only, code only, both with priority, automatic tie-break, upgrades-only, downgrade, and missing discount_code/shop_installed_at.
4. Charge-path parity tests: billing-page display and actual charge must use the same verdict.
5. Outage/fail-safe simulation: confirm automatic and targeted discounts are withheld from display and charge, and plain coded discounts still fail-safe.
6. Pilot with a low-risk plan or merchant cohort, then decide on production rollout, fork, or reject.

Do not put this on the critical billing path before steps 4 and 5 pass.

Operational Impact

Maintenance. Assume we own this code. The package now touches billing and discount behavior, so maintenance is more than dependency hygiene: it requires recurring billing regression coverage, App Manager backend version tracking, and monitoring of discount resolution. Pin an exact version, commit the lockfile, and keep a fork path. Budget monthly review for this dependency during active use, not just a few hours per quarter, because failures are revenue- and merchant-visible.

Support. There is effectively no vendor support channel. Documentation is likely thin and oriented to HulkApps’ own apps. Support and finance teams will need a runbook for “discount missing,” “discount not charged,” and “App Manager outage” scenarios. Engineers will read the source; that is acceptable for a small SDK, but not for billing behavior without tests.

Scaling. The SDK is in-process, but 3.7.0 introduces calls to /plans and /automatic-discount on billing/charge paths. Those are not high-volume paths for most Shopify apps, but they are latency- and availability-sensitive. Instrument endpoint latency and failure rates during the pilot. If plan listing is hit frequently, cache carefully without breaking discount correctness.

Failure modes to plan for:

• App Manager backend without MGR-97 causing missing or incorrect promotional discounts.
• Billing-page display and actual charge diverging due to different discount verdicts.
• Automatic/coded discount priority misapplied, especially tie-breaking.
• “Upgrades only” evaluated incorrectly, producing discounts on downgrades or missing valid upgrades.
• Missing or stale discount_code / shop_installed_at producing silent discount loss.
• App Manager outage withholding automatic and targeted discounts by design, creating merchant confusion and support load.
• Route or controller collisions around /plans, /automatic-discount, or ChargeController::process().
• Vendor abandonment leaving an unpatched billing dependency we cannot upgrade independently.
• Facade or vendor namespace leakage into domain code, defeating the adapter strategy.

Ramp-up. Package code may still be readable in an hour, but the billing/discount domain is not. New engineers need Shopify billing context, the MGR-97 dependency, fail-safe semantics, and the display/charge parity model. With an adapter, decision record, and billing runbook, ramp-up is roughly two to three days for productive work on this area. Without those, it is unsafe.

Verdict. This release changes the assessment materially: the package is a Shopify App Manager billing/discount SDK, not a generic Laravel app manager. It is only worth pursuing if we are on that stack and need App Manager-managed promotional discounts. Provenance remains weak, and the revenue-path surface raises the bar. Gate adoption on confirmed MGR-97 deployment, display/charge parity tests, fail-safe outage testing, and a feature-flagged pilot. Keep the fork as the default exit.