Communication Laravel Package

Product Decisions This Supports

• Feature scoping for outbound-email visibility. The package owns the persistence layer for sent mail plus the settings surfaces around it (mail senders/SMTP, marketing settings, communication settings). If a roadmap item is "let support see and resend what we sent a customer," or "let admins change sender/SMTP without a deploy," this is the buy-side option against building those tables, screens, and audit trail in-house.
• Build vs. buy. Building sent-mail logging + sender management yourself is a few sprints of schema, admin UI, and edge cases (per-tenant senders, marketing vs. transactional separation). This package is a candidate to skip that work — but at v0.5.0 it is pre-1.0, so the buy decision should include a maintenance/upgrade budget, not just an install.
• Data model and compliance decisions. The consolidated schema is now the canonical shape: one sent-mail store, senders separated from marketing/communication settings. That's the structure analytics, retention/export, and "who did we email and when" reporting would be built on. Treat it as the source of truth before designing any reporting or data-retention feature.
• Upgrade-path policy as a product decision. v0.5.0 drops the upgrade-only migrations, so supported upgrade paths are now narrow (v0.4.12 → v0.5.0). Product needs to decide: do we pin, do we maintain a stepwise upgrade runbook, or do we treat this as fresh-install-only for new tenants? That answer determines support burden and onboarding docs.
• Roadmap signal. Collapsing 9 migrations to 3 with final schemas and deleting legacy compatibility code is typical pre-1.0 stabilization. Reasonable to plan around a stabilizing surface, but not to assume API/route stability yet.
• Use cases this unlocks: support-initiated resend of a receipt or notification, deliverability/audit review of outbound mail, per-tenant or per-brand sender configuration, and separating marketing preferences from transactional send settings.

When to Consider This Package

Consider it when:

• You're on a supported Laravel version and need first-party persistence of outbound mail plus admin-editable sender/SMTP and communication/marketing settings — without building those screens.
• You can start fresh on v0.5.0, or you can commit to the documented path: install v0.4.12 first, run php artisan migrate, then upgrade. The retained create-migration filenames mean nothing re-runs — a clean, low-risk upgrade if sequenced correctly.
• You're willing to pin the version and re-check release notes each bump (pre-1.0, breaking changes expected).
• Your team can own the small amount of glue: routes, navigation, and any links into the sent-mail views.

Look elsewhere or defer when:

• You're upgrading from v0.3.x or earlier and skipping v0.4.12. The marketing rename and SMTP→senders data move were upgrade-only migrations and are now gone. Jumping straight to v0.5.0 risks orphaned/mis-shaped data with no migration to fix it. Enforce the stepwise path or don't adopt yet.
• Anything depends on the removed routes — /sent-mails, /sent-mail/{id}, /marketing-settings, /communication-settings. The 301 redirects are gone, so bookmarks, in-app links, emails already sent to customers, and any external integration or status-page link will 404. If you can't inventory and update those references, wrap or defer.
• You need a full email service provider (campaign builder, deliverability tooling, list management, bounce handling at scale). This is not an ESP replacement; pair it with SES/Postmark/etc. rather than substituting.
• You only need SMTP credentials per app. Laravel's own mail configuration and env/secrets management are lighter than adopting a package for it.
• You require post-1.0 stability guarantees — semver-stable routes, published deprecation windows. Not yet.

Adoption checklist before committing: confirm Laravel/PHP support matrix, run the two-step upgrade on a production-like copy with real data and verify marketing/SMTP records landed correctly, grep the codebase and sent-email templates for the four removed routes, and add a pin plus a changelog-review step to your dependency routine.

How to Pitch It (Stakeholders)

For executives (one paragraph): This package gives us outbound-email history and admin-managed sender/communication settings in Laravel without building and maintaining that ourselves — it supports support-team resends, audit/"what did we send" questions, and per-brand sender configuration. It's pre-1.0 (v0.5.0), and this release is a breaking cleanup: the database schema is now consolidated into a single migration set (9 → 3 files) and legacy compatibility code and redirects were deleted. Practical impact: new installs are simpler and faster to stand up; existing installs must upgrade via v0.4.12 first, and a handful of old settings/sent-mail URLs stop working, so anything linking to them needs updating. Recommend adopting with a pinned version and a scheduled upgrade window rather than a continuous-upgrade assumption, and budgeting a small amount of ongoing maintenance until 1.0.

For engineering (bullets to align on):

• What changed: 9 → 3 migrations, each create migration now carries the final schema. Upgrade-only migrations (marketing rename, SMTP→mail senders, column drops) and four legacy 301 redirects removed.
• Upgrade procedure — mandatory order: install v0.4.12 → php artisan migrate → upgrade to v0.5.0. Create-migration filenames are unchanged, so nothing re-runs; this is the intended safety property. Do not jump from older versions directly.
• QA focus: upgrade a production-like DB copy and verify marketing settings and sender/SMTP records moved correctly; confirm no duplicate-table or re-run behavior; smoke-test sent-mail listing and detail views.
• Route removal: inventory and rewrite references to /sent-mails, /sent-mail/{id}, /marketing-settings, /communication-settings — including links embedded in already-sent emails and external bookmarks. Consider adding our own thin redirects if external references are unavoidable.
• Hygiene: pin the exact version, review release notes per bump, and keep fresh-install and upgrade paths tested separately — the consolidation makes these two paths diverge for the first time.