Product Decisions This Supports
- Build vs. buy for email list management. This package is the integration layer for the "buy" side of the decision: self-hosted Sendy (one-time
$69 license) plus Amazon SES ($0.10 per 1,000 emails) instead of a recurring Mailchimp/ConvertKit bill. The package itself is a thin Laravel API client — it doesn't make the decision, it makes the decision cheap to execute.
- Feature scoping for subscription and preference flows. Anything that touches "add user to list," "unsubscribe," "check subscription status," or basic custom-field capture can be shipped without building list infrastructure. That covers newsletter signup, gated-content unlocks, waitlists, and lightweight preference centers.
- Roadmap sequencing. If email is a supporting capability rather than a core product surface, this lets you defer investment in a proper ESP/CDP integration. If email automation, journeys, or deliverability analytics are on the roadmap, this package does not clear that bar and should be treated as a stopgap.
- Vendor exit optionality. Wrapping Sendy behind a Laravel service class means an ESP migration later is a bounded refactor rather than a hunt through controllers. Worth designing the abstraction deliberately rather than calling the package directly from application code.
- Signal check on maturity. 71 stars, zero dependents, single maintainer, last release January 2024. It is not a strategic dependency; it's convenience code. Factor that into how much of your architecture you let lean on it.
When to Consider This Package
Consider it when:
- You already run Sendy, or have decided to. This is an API client — it is inert without a Sendy installation behind it.
- You're on Laravel/PHP and want subscribe/unsubscribe/list operations without hand-rolling Guzzle calls against Sendy's endpoints.
- Your email needs are campaign-shaped and modest: newsletter lists, basic segmentation, custom fields. Not transactional receipts, not lifecycle automation.
- Your volume makes SES economics compelling and you have someone who can own a PHP/MySQL server, cron jobs, and SES production access.
- You're comfortable treating the package as a starting point you may fork. At this size, "maintained" means "readable and pinnable," not "actively iterated."
Look elsewhere when:
- You need transactional email. Use Laravel's Mail facade directly against SES/SESv2 or Postmark. Sendy is a campaign tool and is the wrong pipe for password resets.
- You need automation, drip sequences, A/B testing, or deliverability reporting — Sendy is thin here and the package exposes only what Sendy offers.
- Your team has no appetite for operating email infrastructure. Self-hosting shifts deliverability, bounce/complaint handling, and CAN-SPAM/GDPR unsubscribe compliance onto you. The package handles none of that.
- You're not on Laravel, or you need a widely-adopted SDK with a support path. Zero dependents means no crowd-sourced bug surface.
- You need guarantees. Verify the package against your Sendy version before committing; a 2024 release against a moving API is a compatibility question, not a certainty.
How to Pitch It (Stakeholders)
For executives — the one-paragraph version: This is small, MIT-licensed glue code that connects our Laravel app to Sendy, a self-hosted email platform. It isn't a platform bet on its own; it's the cheap path to a real decision — replacing a recurring email vendor bill with a one-time license plus pay-per-email sending. The cost case is straightforward: a few hundred dollars a month becomes roughly seventy dollars once plus fractions of a cent per message. The engineering cost is days, not weeks. The risk is operational rather than technical: we'd own the server and the sender reputation. Recommendation is to pilot on one low-stakes newsletter flow, measure deliverability and ops load for a quarter, then expand or unwind. Because the integration is thin and isolated, unwinding is cheap.
For engineering — what you're actually signing up for: A thin client, not a framework. Read the source before adopting, pin the version, and wrap it in your own service so you control the seam. Budget for the parts the package doesn't cover: SES production access and warm-up, bounce and complaint webhook handling, unsubscribe compliance, and a scheduled job for Sendy's cron. Assume you own any bug fixes. The upside is that the surface area is small enough that owning it is realistic — this is closer to vendoring a helper than adopting a dependency.
For the pilot — success criteria: Deliverability within a few points of the incumbent, unsubscribe handling that passes a compliance review, and under a day a month of operational attention. If any of those miss, the abstraction makes the exit a sprint task rather than a quarter.