Case study: why this plugin was built in the first place

This plugin came from a real client problem, not a theoretical feature list. The client ran a content and course business on WordPress, sold through MemberPress, and used MailerLite for email marketing and customer communication.

The setup

  • MemberPress handled courses, memberships, and purchases.
  • MailerLite handled subscriber groups and email communication.
  • Zapier sat in the middle for purchase-based syncing.

The business risk

  • Missed syncs meant missed onboarding and follow-up emails.
  • New customers had to be checked manually.
  • The workflow had become business-critical, not optional.

What went wrong

After a domain migration, the old MemberPress to Zapier to MailerLite setup stopped being a clean fit. The buyer needed the sync to keep working, but the route back through MemberPress API access and Zapier had become harder than it should have been.

There were three practical constraints: stay on the MemberPress Growth plan, avoid adding more recurring tool overhead, and make future product launches manageable without code changes.

Constraint

Stay on MemberPress Growth and avoid a forced platform upgrade.

Requirement

Map products to MailerLite groups from admin without touching code.

Need

Make the sync visible enough to debug if a real purchase failed.

What was built

  • A direct MemberPress to MailerLite integration inside WordPress
  • A no-code product-to-group mapping screen
  • Bulk sync for existing members
  • Activity logging and fallback hooks for reliability
  • Lifecycle-aware handling for expiry and refunds

The outcome

The client ended up with a simpler system that fit the actual business workflow better than the old automation chain. New signups were syncing properly, missing mappings were easier to spot, and the owner no longer had to keep checking whether Zapier had quietly failed.

That is the product now being sold here: not “all automation,” just a better answer to this specific problem.