DEV Community: Connor

Building a Behavior-Based Email Welcome Flow Without Complex Automation

Connor — Fri, 30 Oct 2026 04:04:09 +0000

Most welcome email systems follow a predictable pattern: subscribe, receive three generic emails, then join a newsletter.

I think we can build something more useful without introducing an expensive automation platform.

Consider an application with 400 newsletter subscribers. Some are beginners, while others already understand your product. Sending identical onboarding messages to both groups wastes an opportunity to personalize communication.

Here's how I would design a lightweight, event-driven welcome sequence with three branches, five possible emails, and a few simple tags.

1. Model Subscribers With Minimal State

I would start with three tags:

beginner
experienced
unengaged

Each subscriber also needs signup time, email preferences, and consent information.

const subscriber = {
  id: "user_123",
  email: "user@example.com",
  tags: [],
  subscribedAt: new Date().toISOString(),
  consent: true,
  unsubscribed: false
};

For production, I would persist this information in a database rather than storing it in memory.

2. Email 1: Capture Intent Immediately

My first email delivers whatever someone requested during signup.

Below download link, I would include two options:

I'm just starting out.
I've been doing this a while.

Each link points to an authenticated preference endpoint.

For example:

GET /preferences?choice=beginner&token=...
GET /preferences?choice=experienced&token=...

One important detail: email security scanners sometimes follow links automatically.

I would therefore show a confirmation page before permanently updating preferences. Tokens must be signed, scoped, and expire after a reasonable period.

Actual preference changes should use a validated POST request.

3. Implement Three Branches

Once preference selection is confirmed, subscriber state determines upcoming emails.

function getWelcomeSchedule(segment) {
  const common = [
    { day: 0, template: "welcome" },
    { day: 8, template: "expectations" },
    { day: 12, template: "next-step" }
  ];

  const branches = {
    beginner: [
      { day: 2, template: "beginner-mistakes" },
      { day: 5, template: "beginner-checklist" }
    ],
    experienced: [
      { day: 2, template: "advanced-tactics" },
      { day: 5, template: "campaign-teardown" }
    ],
    unengaged: [
      { day: 3, template: "preference-reminder" },
      { day: 5, template: "general-example" }
    ]
  };

  return [...common, ...branches[segment]]
    .sort((a, b) => a.day - b.day);
}

This function returns five scheduled messages for any supported segment.

I would initially classify subscribers without a preference as unselected, using unengaged only after a defined inactivity period.

4. Schedule Emails Reliably

For a small application, a queue worker or scheduled job is sufficient.

Every scheduled message should have a unique key:

const jobKey =
  `${subscriber.id}:${templateId}`;

Before sending, I would check:

Has this message already been sent?
Is subscriber consent still valid?
Has someone unsubscribed or reduced frequency?
Has their preferred segment changed?

A database-backed uniqueness constraint and transactional job claiming can prevent duplicate sends across workers.

I would also suppress outdated branch messages whenever preferences change.

5. Measure Actual Engagement

Open tracking is increasingly unreliable because of privacy protections and automated activity.

I prefer measuring confirmed preference selections, meaningful clicks, replies, and unsubscribes.

Consider a hypothetical 400-subscriber cohort:

Segment	Subscribers
Beginner	120
Experienced	80
No selection	200

Initial preference selection:

(120 + 80) / 400 * 100 = 50%

If another 20 subscribers choose a preference after receiving a reminder:

220 / 400 * 100 = 55%

That's a five-percentage-point increase in known preferences, not proof of improved revenue or retention.

For accurate reporting, I would exclude detected bot activity and track each cohort separately.

6. Avoid Overengineering

Small mailing lists rarely need complex customer-data infrastructure.

Before selecting an email service provider, I would evaluate automation support, API limits, webhook reliability, and pricing.

For additional platform context, Sprout24 maintains an independent email marketing software comparison directory.

I would also implement unsubscribe handling, bounce processing, retry limits, suppression lists, and relevant email authentication requirements before going live.

Final Thoughts

My preferred architecture is straightforward:

Signup → Welcome Email → Preference Selection → Branch Scheduling → Engagement Measurement

No complicated scoring engine is necessary.

I'd start with explicit user preferences, add behavior-based segmentation only when useful, and improve implementation using real subscriber feedback.

How would you handle preference changes while multiple email jobs are already queued?

Id be interested in comparing approaches using database jobs, queue workers, or serverless functions.

Mailchimp vs MailerLite in 2026: I Did the Math on Free Plans, Sending Limits, and Switching Costs

Connor — Wed, 28 Oct 2026 12:25:12 +0000

I was comparing email marketing costs for a small ecommerce setup recently, and one question kept bothering me:

How much does a free email marketing plan actually let you do in 2026?

Imagine managing 200 subscribers and sending four newsletters every month. Nothing complicated. Just product updates, occasional promotions, and some automated follow-ups.

At first glance, both Mailchimp and MailerLite appear suitable.

But when I checked current sending allowances, I found a meaningful difference.

MailerLite permits 2,500 monthly emails on its free plan. Mailchimp permits 500.

That changes how I would approach platform selection, especially for developers building email workflows into small applications.

Let's break down actual numbers.

1. Free email plans became more restrictive in 2026

MailerLite updated its free plan on June 16, 2026.

Subscriber capacity dropped from 500 to 250, while monthly sending allowances decreased from 12,000 to 2,500 emails.

That represents:

50% fewer permitted subscribers
79.2% reduction in monthly sending capacity

MailerLite also introduced additional free-plan capabilities, including more editing options and two account seats.

Mailchimp currently permits 250 contacts and 500 monthly emails, subject to a 250-email daily sending limit.

Here is my comparison based on published vendor documentation.

Feature	MailerLite	Mailchimp
Free contact limit	250	250
Free monthly sends	2,500	500
Daily free sending limit	Check account terms	250
Entry paid plan	Comfort	Essentials
Advertised starting price	$12/month	$13/month

Sources: MailerLite pricing and Mailchimp pricing.

Prices are USD starting rates, not personalized quotations. Subscriber tiers, promotions, taxes, billing terms, and regional pricing can affect final costs.

2. I calculated how quickly each free plan runs out

Consider a hypothetical newsletter application with these requirements:

Active subscribers: 200
Campaigns per month: 4
Recipients per campaign: 200

Monthly emails = 200 × 4
              = 800

MailerLite:

Monthly allowance: 2,500
Monthly requirement: 800

Remaining capacity = 1,700
Usage = 32%

Mailchimp:

Monthly allowance: 500
Monthly requirement: 800

Shortfall = 300 emails
Usage required = 160% of allowance

Both platforms accommodate 200 contacts, but only MailerLite supports this specific sending workload on its free tier.

Something interesting happens when I extend calculations across a full year.

Annual sending requirement:
800 × 12 = 9,600 emails

MailerLite free annual capacity:
2,500 × 12 = 30,000 emails

Mailchimp free annual capacity:
500 × 12 = 6,000 emails

These annual totals assume unchanged monthly allowances and no unused capacity rolling forward.

For this use case, MailerLite provides enough free sending capacity, while Mailchimp requires a change in plan or sending strategy.

That is a practical difference, not merely a pricing-page comparison.

3. Starting prices tell only part of a story

MailerLite Comfort starts at $12 monthly. Mailchimp Essentials advertises a $13 monthly starting rate.

For illustration, assuming these rates remain applicable for twelve months:

MailerLite:
$12 × 12 = $144/year

Mailchimp:
$13 × 12 = $156/year

Difference:
$156 - $144 = $12/year

Would I recommend migrating an entire email system to save $12 annually?

Probably not.

These calculations also do not establish that both plans provide identical contact capacity or functionality.

A production email setup might depend on signup forms, CRM synchronization, scheduled campaigns, customer segments, event-driven automations, and analytics integrations.

Migrating those workflows can cost significantly more than a small subscription difference.

I would treat subscription pricing as one variable in a larger total-cost calculation.

4. What about AI-powered email features?

Both products increasingly emphasize automation and AI-assisted workflows.

MailerLite Comfort includes AI writing assistance, smart sending, and advanced campaign testing capabilities.

These features can be useful, but I prefer measuring productivity gains rather than assuming every AI feature produces better marketing results.

Imagine paying $20 extra monthly for a hypothetical premium capability that saves two working hours.

Monthly additional cost: $20
Time saved: 2 hours
Internal hourly value: $25

Estimated labor value:
2 × $25 = $50

Net estimated benefit:
$50 - $20 = $30/month

Under those assumptions, upgrading makes financial sense.

But if a feature saves only ten minutes monthly, calculation changes dramatically.

I would also measure conversion performance, revenue per recipient, and campaign preparation time.

AI-generated subject lines alone are not evidence of improved ROI.

5. What developers should check before migrating

If I were integrating an email platform into a SaaS application, I would start with a technical audit.

My checklist would include:

API compatibility: Can existing subscriber operations and integrations be recreated?
Webhook support: Can subscription changes and other important events reach my backend?
Automation portability: Which workflows must be rebuilt manually?
Authentication: Are SPF, DKIM, and DMARC configured correctly after migration?
Data integrity: Can consent records, subscriber fields, segments, and suppression lists be transferred safely?
Usage limits: How do subscriber tiers, sending quotas, and plan restrictions change as volume grows?

I would test critical workflows in a staging environment before moving production traffic.

A cheaper subscription is not necessarily cheaper infrastructure.

For broader research, I also refer to email marketing platform alternatives when exploring products beyond these two vendors.

6. My conclusion after running numbers

MailerLite looks particularly attractive for smaller teams with modest subscriber lists and relatively frequent newsletters.

Mailchimp may remain a sensible choice when existing integrations, established automations, and migration complexity outweigh potential savings.

What surprised me most was not a $1 difference between advertised starting prices.

It was how dramatically free sending allowances differ.

For my 200-subscriber example, one platform accommodates four newsletters monthly, while another does not.

My advice is simple: calculate your sending requirements before comparing feature lists.

A few lines of arithmetic can reveal more about platform suitability than dozens of marketing claims.

I'm curious how other developers handle this.

When choosing an email platform for a side project or SaaS application, do you prioritize free sending capacity, API flexibility, automation features, or long-term pricing?

Research note: Pricing and plan limits checked against official MailerLite and Mailchimp documentation on October 28, 2026. Examples are hypothetical and calculations are illustrative, not reported client outcomes. This article was prepared with AI writing assistance and should be fact-checked by its publishing author.