Appmanager Laravel Package

Product Decisions This Supports

• Build vs. buy on Shopify app plumbing — now with a sharper edge. The 3.7.0 release confirms this is not a self-contained boilerplate library but a client SDK for a HulkApps-hosted "App Manager" backend: the discount verdict is computed server-side and fetched via /plans and /automatic-discount, and the release explicitly requires App Manager with MGR-97 deployed. The build-vs-buy question is therefore really build vs. buy vs. depend on a vendor service, and the PM decision must be scoped accordingly. Verify the actual surface area and the service dependency before relying on this.
• Promotional pricing and discount mechanics. The new capability is product-facing, not infrastructure: automatic discounts (no code required), code-based discounts, priority-based winner selection, per-plan value/type/cycle application, and an "upgrades only" gate that applies a discount solely when the target plan costs more than the merchant's current plan. That is a merchandising toolkit — it enables acquisition promos, win-back offers, annual-upgrade incentives, and downgrade protection without bespoke billing code.
• Pricing experimentation integrity. The stated design property — "the billing-page display and the actual charge share one verdict" — is the thing that makes discount experiments trustworthy. Divergent display-vs-charge logic is a support-ticket and trust-destroying bug class; a single resolved verdict per plan materially de-risks running price/promo tests.
• Portfolio economics. If the roadmap includes multiple Shopify apps on a shared Laravel codebase, centralizing app identity, scopes, billing, and now discount targeting in one App Manager integration lowers marginal cost per app. That remains a platform-shaped bet, appropriate for a roadmap review rather than a sprint.
• Time-to-market for a first Shopify release. Still a candidate to compress idea → App Store listing, and the discount layer is work most teams would otherwise defer or hand-roll badly.
• Explicitly not supported: anything outside Shopify, and anything that must function independently of HulkApps' App Manager service. Do not let this set a precedent for core platform abstractions.

When to Consider This Package

Consider it when:

• You are building one or more embedded Shopify apps in Laravel and the install/webhook/billing/discount layer is genuinely blocking your first release or your first promotional campaign.
• You are willing to depend on the App Manager backend, including keeping it version-matched (3.7.0 requires MGR-97 server-side). Treat the SDK and the service as one adoption decision, not two.
• Promotional discounting with per-plan targeting and upgrades-only semantics is on your near-term roadmap — that is the differentiated capability this release adds, and it is the strongest reason to prefer this over generic Shopify billing libraries.
• You can read the source and confirm the targeted Shopify API version and billing model match current requirements.
• You are comfortable owning a fork. At 0 stars and 0 dependents you are effectively the only user — treat it as vendored code you maintain.
• MIT licensing clears your legal/procurement path, which it does.

Look elsewhere when:

• You need vendor support, an SLA, or a security review trail. Zero dependents still means zero field-testing; a payment-adjacent billing and discount layer with no external users is a risk you accept, not inherit.
• You want no runtime dependency on a third-party service. The discount path is live-path only and deliberately disabled during App Manager outages — automatic and targeted discounts are neither shown nor charged, while plain coded discounts still fail-safe. If silent discount withdrawal during an outage is unacceptable for a running campaign, that is a product constraint, not an implementation detail.
• Data flow is a blocker: getPlans() forwards discount_code and shop_installed_at to the vendor endpoint. Confirm what shop and merchant data leaves your app and that it clears your privacy/data-handling review.
• A maintained alternative exists — official Shopify PHP/Laravel libraries or established community packages. The one thing that now argues against "ecosystem size is the feature" is that this release codifies a specific discount-targeting model; if you need that model, it is genuinely differentiated.
• The dependency is disproportionate: for a thin internal tool, the abstraction plus service coupling exceeds the boilerplate saved.

Diligence gate before any commitment: the 3.6.2 → 3.7.0 delta is real evidence of a maintained, versioned release train and largely retires the earlier staleness concern — but confirm commit recency, test coverage, Shopify API version support, webhook HMAC verification, the App Manager version-matching/upgrade policy, and outage behavior during a live promotion. Timebox this to a spike with a defined exit. Note the prior metadata oddity (a listed last release dated 2026-10-14, post-dating the review) and the weak composite score (~20/100, opportunity 48); the new tag improves the picture but does not erase it.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel SDK that removes real work from our Shopify apps — the install, webhook, billing, and now promotional-discount plumbing that every app needs and no customer ever sees. The 3.7.0 release adds automatic and code-based discounts with per-plan targeting and an upgrades-only rule, with one resolved verdict driving both what the merchant sees and what we charge — which is what makes running pricing promotions safe. The honest caveats: it is a client for a HulkApps-hosted service, so we depend on their backend and must keep versions matched; and during their outages automatic discounts are intentionally withheld. Recommendation: fund a short, timeboxed spike that produces a working install-and-discount flow or kills the option — do not put it on the critical path until that passes, and do not run a live campaign on it without an outage plan.

To engineering: Evaluate the source and the service contract. Specifically: Shopify API version targeted, HMAC verification on webhooks, billing state-machine correctness, the discount resolution precedence (automatic plus code, automatic breaking ties), how shop_installed_at and discount_code are transmitted, the fail-safe boundary, and how much of our app it forces into its conventions. Assume we may fork it; confirm that is tractable. Return a go/no-go with a written assessment of what we would still build ourselves and what breaks during an App Manager outage.

Framing to avoid: Don't position this as a strategic platform choice or as free differentiation. It is a schedule and merchandising lever with a vendor dependency and a maintenance tail, and it should be justified on weeks saved against a credible build-it-ourselves estimate.