Saasus Sdk Php Laravel Package

Product Decisions This Supports

• Build vs. buy for the SaaS control plane. The SaaSus Platform PHP SDK fronts the infrastructure we would otherwise hand-build: tenant provisioning, user/auth (incl. SSO), pricing plans and menus, subscription and metered billing, Stripe integration, and usage logging. Adopting it turns a multi-quarter platform build into an integration task.
• Monetization roadmap sequencing. Anything that depends on plans, tiers, seats, or usage-based charges (paid tiers, self-serve upgrade/downgrade, enterprise plans, trials) can be scheduled earlier because the SDK already exposes those primitives via API.
• Multi-tenant architecture decision. Whether SaaSus becomes the source of truth for tenants and identities, or we keep our own tenant table and sync. The SDK being a thin, typed REST client (not an opinionated framework package) means we can adopt it behind our own adapter and defer the lock-in decision.
• Feature-level use cases to scope: B2B tenant onboarding, per-seat pricing, Stripe-backed checkout, SSO for enterprise buyers, metering for API/AI usage.
• Vendor/exit-cost analysis. Because it is an SDK rather than a framework-coupled package, a swap-out is contained to our integration layer — a materially lower risk profile than a hosted control plane with deep app coupling.

When to Consider This Package

Adopt when: we are already on (or actively trialing) SaaSus Platform; the app is PHP/Laravel and comfortable calling a Composer-installed REST client; the team is small enough that tenant/auth/billing infrastructure is a genuine distraction; and we can afford to own the Laravel glue (service container bindings, config, error mapping, webhook handling) ourselves.

Look elsewhere when: we are not a SaaSus customer (the SDK is useless standalone); we need a first-class Laravel package (service provider, publishable config, migrations, facades, queue-aware webhooks) — this is a plain SDK; we need vendor-neutral billing (Laravel Cashier or a direct Stripe integration is the better comparison); or we require English-language documentation and release notes — v1.10.10's notes are Japanese-only, which is a real onboarding and support consideration for a non-Japanese-reading team.

On this release specifically: v1.10.10 is a non-functional patch. It only adds a GitHub Actions workflow for publishing the package, plus a first-time contributor. No API changes, no deprecations, no breaking changes, no new capabilities. The practical PM read is distribution maturity — automated publishing means more predictable, verifiable releases from Packagist rather than manual tags — which slightly reduces supply-chain/maintenance risk in a procurement review. It is safe to bump; there is nothing to re-plan around.

How to Pitch It (Stakeholders)

To executives: This is a buy-not-build lever for the monetization surface — tenants, plans, billing, SSO. It compresses the path from "feature complete" to "charging customers" and avoids staffing a platform team for undifferentiated infrastructure. The trade-off to approve is a commercial dependency on SaaSus Platform plus a contained integration layer we control. Recent releases are maintenance-grade (v1.10.10 is CI/publishing only), so the cost of adoption is stable, not a moving target.

To engineering: composer require a typed PHP client that maps to SaaSus REST endpoints. It is intentionally not a Laravel package — no service provider, no migrations, no facades — so we own the wiring: bind a client in the container, isolate all calls behind our own interface (this is also our exit hatch), centralize error/retry handling, and treat webhooks as untrusted input. Upgrade to v1.10.10 is a no-risk patch that adds an automated publish workflow, improving release provenance. Flag for the team: docs and changelogs are largely Japanese, so budget time for a short internal integration note.