Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy on marketing automation. This package is a thin Laravel facade over the fopost/sdk, covering broadcasts, drip sequences, WhatsApp, Meta Ads, Google Business Profile, blog publishing, media uploads, and an activity feed. It lets you evaluate "integrate rather than build" for multi-channel campaign orchestration without standing up your own scheduler, channel adapters, and asset pipeline.
• Channel roadmap sequencing. The v0.2.0 facade surface (broadcasts(), drip sequences, whatsapp(), googleBusiness(), meta ads) is effectively a menu of channels you can ship in a sprint rather than a quarter. Useful for deciding which channel to launch next based on effort-to-reach, not engineering capacity.
• Campaign lifecycle feature scoping. Broadcasts + drip sequences + activity resource map directly onto common PM epics ("send once," "nurture sequence," "audit what was sent"). You can prototype these journeys against a real backend before committing to your own data model.
• Asset and content operations. media() for direct uploads and inbound blog article handling cover the "creative + content" side of campaigns — relevant if you're weighing whether content publishing belongs in your product or in a third-party tool.
• Integration surface for lifecycle/CRM features. The activity resource gives you an event-ish view of what the platform did, which is the minimum viable input for in-app notifications, admin dashboards, or customer-facing "what we sent you" screens.
• De-risk spikes, not production commitments. At v0.2.0 with a single maintainer, this is best positioned as a way to validate demand and UX cheaply, not as a load-bearing dependency for a revenue-critical feature.

When to Consider This Package

Consider it when:

• Your stack is Laravel/PHP and you want channel integrations (WhatsApp, Meta Ads, Google Business, blog distribution) as facade calls rather than bespoke API clients per channel.
• You need multi-channel campaign primitives — broadcasts, drip sequences, media uploads — and are comfortable with the vendor (Fopost) owning the scheduling and delivery layer.
• You're validating a marketing-adjacent feature (notifications, nurture flows, content distribution) and want to ship a thin slice in days.
• You accept vendor lock-in and data residency in exchange for speed, and your volume is within the vendor's published limits.
• You can tolerate pre-1.0 churn: v0.2.0 bumps the SDK requirement (now ^0.3) and has already changed the required SDK twice in one release cycle.

Look elsewhere when:

• You need contractual SLAs, uptime guarantees, or a support path beyond a single GitHub maintainer.
• Your differentiation depends on the campaign logic itself (custom eligibility rules, complex frequency capping, proprietary send-time optimization) — a facade over someone else's engine constrains that.
• You need data ownership/export guarantees, strict compliance posture (e.g., regulated messaging consent flows you must own end-to-end), or on-prem/regional hosting.
• Your stack isn't PHP/Laravel, or you need first-class typed clients and stable semver (1.0+) before adopting.
• You expect high message volume where per-message vendor pricing dominates — model unit economics before committing.

How to Pitch It (Stakeholders)

For executives: This is a buy-not-build decision for multi-channel campaign delivery. A single Laravel integration gives us WhatsApp, Meta Ads, Google Business, blog distribution, broadcasts, drip sequences, and media handling — capabilities that would otherwise be several quarters of integration work across four external APIs. The trade-off is vendor dependency and maturity: the package is at v0.2.0, maintained by one person, and its SDK requirement moved twice in this release alone. Recommend we treat it as a fast validation path, not a platform commitment: timebox a spike against one channel, confirm the vendor's pricing and delivery guarantees, and only then decide whether to standardize. What we're buying is speed and optionality; what we're deferring is control over the delivery engine.

For engineering: It's a thin facade over fopost/sdk, so most behavior — and most risk — lives upstream. The facade now exposes media(), activity(), whatsapp(), googleBusiness(), plus broadcasts and drip sequences. Note the dependency pin moved to ^0.3 in this release and the SDK was previously pinned to ^0.2 "until 0.3 is published" — expect breaking changes between minor versions. Keep the integration behind an internal interface (a CampaignGateway-style abstraction) so swapping vendors is a contained change, and pin the SDK version explicitly in composer.lock rather than floating. Also worth flagging: the changelog is dominated by CI, test, and release-workflow changes — good hygiene, but it means the package is still being stood up as a project. Budget time for reading the SDK source rather than relying on docs.

Ask: one two-week spike, one channel, a written go/no-go against cost-per-message, data-handling, and support terms.