Blazalek.com
Youmoney

02 / 03YoumoneyFintech lending marketplace

Scaling toward a million sends a day on a new engine

How I moved a high-volume lending marketplace onto a new event-driven sending engine and rolled it out safely, phase by phase.

By

Scale
~1M sends/day target
Journeys
5 event-driven automations
Rollout
Phased, reversible ramp

In short

Business risk
Email drives most of the customer journey on a high-volume lending marketplace: from unfinished application to loan taken. A botched migration could put deliverability, and revenue, at risk.
What was broken
A legacy, tag-based marketing platform whose lifecycle logic and consent handling were hard to extend and hard to trust at scale.
What I changed
Migrated to a new event-driven sending engine: ~5 clean lifecycle journeys triggered on real events, per-type consent, multi-provider sending with warm-up, and a phased, reversible rollout.
Measurable result
Live traffic moved onto the new engine safely, one measured step at a time, with per-automation and per-email visibility the team never had before.
Current state
In production and ramping (2026–present). The architecture is built to scale toward ~1M sends/day: a target capacity it's designed for, not an achieved daily volume.

The starting point

Youmoney runs a high-volume lending marketplace where email drives most of the customer journey: from an unfinished application to the loan being taken. Everything sat on a legacy marketing platform built on tags, with lifecycle logic and consent handling that were hard to extend and hard to trust at scale. They wanted to move to a new, event-driven sending engine and grow toward roughly a million sends a day, without ever putting deliverability at risk during the switch.

My approach

I treated this as an infrastructure migration first and a marketing project second. Before touching a single send, I mapped how a user actually moves through the funnel and turned that into a small set of clean, event-driven journeys the engine could trigger on real signals rather than fragile tag combinations. From there the rule was simple: integrate properly over API and webhooks, warm up quietly in the background, and let live traffic onto the new system in small, measured percentages so every step was reversible and observable.

The process

  1. 01

    Discovery and mapping

    I sat down with the team to map the real customer journey: from an unfinished application, through the offer, to the loan being taken or rejected. We agreed on the exact events that mark each transition and how a user is identified across multiple applications.

  2. 02

    Designing the journeys

    I translated that map into roughly five event-driven automations: abandoned application, offer follow-up, post-conversion upsell, rejection re-engagement and a repayment-window nudge. Each journey starts, stops and branches on real events, with deliberate delays so a user isn't emailed before they've had a chance to finish.

  3. 03

    API and webhook integration

    I integrated the new engine over API and webhooks: inbound events driving the journeys, and outbound signals for consent changes, suppression entries and hard bounces or complaints, each with a clear reason. Consent was reworked so an unsubscribe removes someone from one specific type of communication rather than blanket-suppressing them.

  4. 04

    Warm-up and provider setup

    I set up sending across Amazon SES and additional providers with rotation rather than a single linear channel, and ran domain and IP warm-up quietly in the background while the journeys were being built. Bounce and rejection rates were the guardrail for how fast we could push.

  5. 05

    Phased rollout

    We moved live traffic onto the new engine in measured steps: starting at a small share of one brand and increasing toward the majority of its traffic, reviewing results before each step up. Higher-risk conversion and upsell messages were sent from separate identities so they couldn't affect the reputation of the core sending.

  6. 06

    Monitoring and reporting

    I stood up per-automation and per-email reporting (unique opens and clicks, step-by-step drop-off and date-range filtering) exposed to the team so they can compare performance over time and spot dips early. Aggregate stats are being shaped into a stable model as volume grows.

The outcome

Youmoney now runs on a new, event-driven sending engine instead of the legacy platform, with lifecycle journeys that trigger on real signals, consent handled per communication type, and multi-provider sending backed by proper warm-up. The rollout has moved live traffic onto the system safely, one measured step at a time, and the architecture is built to scale toward roughly a million sends a day. They now have per-automation and per-email visibility they didn't have before, so growth happens with the numbers in view rather than in the dark.

Stop guessing why your emails don't arrive. Let's diagnose it in a 30-minute call.

Delivery check

We'll walk through your symptoms and sending volume. You'll leave with a concrete hypothesis, a risk assessment and a plan for what's next. Whether or not we end up working together.