Product Decisions This Supports
- ESP / vendor selection (the real decision). This package exists to make "Sendy + Amazon SES" a viable option against Mailchimp, ConvertKit, Customer.io, or Loops. Adopting it is not an architecture decision — it's the cheap validation step that lets you price out a self-hosted, flat-cost newsletter stack before committing.
- Build vs. buy for the integration layer. The package is a thin, MIT-licensed API wrapper (subscribe, unsubscribe, delete, list status). A PM should treat it as a buy-at-zero-cost, own-forever artifact: the decision is whether the ~1–2 days of engineering to replicate it is worth more than the cost of carrying an unmaintained dependency. In most cases it's a coin flip, which tells you the integration itself is not a differentiator.
- Roadmap scoping for lifecycle/CRM features. Because Sendy's API surface is narrow (list and subscriber operations, no rich automation, no transactional sending), the package implicitly bounds what your product can promise. If the roadmap includes drip sequences, behavioral triggers, or in-app transactional email, this integration is a dead end and should be scoped out early.
- Cost curve at scale. Sendy's economics (one-time license + SES per-email pricing) versus per-contact SaaS pricing is the decision that actually moves the P&L. This package is the instrument that lets you pilot that curve with real subscriber data instead of a spreadsheet.
- Compliance and data-residency posture. Self-hosting Sendy keeps the subscriber database in your infrastructure. If "where does our list live" is an open question from legal or enterprise buyers, this stack answers it — and the package is the only code you need to prove it out.
When to Consider This Package
Adopt when all of the following hold:
- You are already on Sendy, or you are running a deliberate two-week spike to evaluate it against a SaaS ESP.
- Your stack is PHP/Laravel and the integration needs are basic: add a subscriber to a list, unsubscribe, delete, check status.
- Volume is low-to-moderate and marketing email is a supporting feature, not the product.
- You are comfortable vendoring or forking the code. Last release was January 2021 and the upstream repo isn't verifiable, so plan to own it: pin the version, copy it into your codebase, and add tests around the API responses you depend on.
- You can live with Sendy's API limitations — no first-class batch operations, no transactional sending, limited webhook support in older Sendy versions.
Look elsewhere when:
- You need a maintained SDK with security patches, PHP 8.2+ guarantees, and responsive issue triage. A four-year-old wrapper on a low opportunity score is a commodity artifact, not a vendor relationship.
- You want Laravel-native ergonomics — config publishing, a facade, queued jobs with retries/backoff, events on subscribe/unsubscribe, HTTP client mocking. This package gives you a class, not an integration; budget the glue code yourself or pick a maintained Laravel mail package.
- You need transactional email (password resets, receipts, notifications). Sendy is a newsletter tool; route that traffic to SES, Postmark, or Resend directly.
- Your stack isn't PHP, or your team has no appetite for owning a fork.
- You're already paying a SaaS ESP and the switching cost exceeds the savings — the package removes the integration excuse but not the migration cost.
How to Pitch It (Stakeholders)
To executives: "We can cut our email marketing spend from per-contact SaaS pricing to SES per-email rates plus a one-time Sendy license. The integration cost is small — the open-source wrapper is a few hundred lines and MIT-licensed, so there's no vendor lock-in and no code we can't own. I'd like one sprint to pilot it with a segment of the list and compare deliverability and cost before we commit. Downside: it's an unmaintained wrapper, so we'd vendor it and support it ourselves — that's roughly a day of engineering, and it's the cheapest way to find out whether the switch is worth it."
To engineering: "It's a thin PHP class over the Sendy API — subscribe, unsubscribe, delete, subscription status. MIT, ~130 stars, last release 2021, upstream unverifiable. Don't treat it as a dependency to track; treat it as starter code. Vendor it, pin it, wrap it in a Laravel service with a config file, queue the writes, and mock the HTTP client in tests. If it turns out to be less work to write our own 200-line client against Sendy's documented endpoints, do that instead — the package's only real value is saving us the first afternoon."
Risk framing to include in either pitch: the technical risk is low because the surface area is tiny; the strategic risk is that Sendy itself, not this wrapper, is the bet. Frame the package as a one-sprint, reversible experiment, not a platform commitment.