In plain terms
ECamp is the software a company uses to email its customers at scale - newsletters, announcements, onboarding sequences - and to see what happened afterwards: who opened, who clicked, who bounced, who complained.
Two things make it different from a simple mailing tool. First, it is built for the failures that cost money: a campaign can be stopped mid-send the moment someone spots a wrong link, and a technical retry can never email the same person twice. Second, contacts can be managed by talking to it - “add everyone who opened the March campaign to a new segment and tag them warm” - with the AI preparing the change and the application deciding whether it is permitted.
Why it matters commercially: in bulk email nothing can be taken back. One duplicated send makes a brand look broken; one careless burst can get a sending domain throttled for weeks, which quietly kills every campaign after it.
The problem
Sending one email is trivial. Sending two hundred thousand is a pacing, reputation and repetition problem where every mistake is permanent. You cannot un-send. And a burst that trips a provider’s threshold damages a sending reputation that takes weeks to rebuild - during which every subsequent campaign lands in spam folders and nobody can tell you exactly why.
ECamp is a platform built around those specific stakes. It also doubles as my Master’s thesis project on AI-assisted campaign management.
Not locked to one email provider
Every organisation configures its own sending route - AWS SES or standard SMTP - and those credentials are encrypted and kept separate per organisation. The application never talks to a provider directly; it talks to a common interface.
The business consequence is leverage: switching provider for price, deliverability or coverage is a settings change rather than a development project, and a provider outage becomes a failover instead of an incident.
Pacing in three layers
A single overall speed limit is not enough, because the real constraints exist at different scopes:
- The provider’s hard ceiling - the limit that must never be crossed, on pain of throttling.
- Per-organisation throughput - so one customer’s blast cannot consume the shared budget and starve everyone else.
- Per-recipient-domain pacing - because large mailbox providers throttle bursts from a single sender, and the polite rate is well below the provider’s own ceiling.
All three are enforced with shared counters that workers consult before claiming a batch. A worker that cannot claim capacity steps aside rather than sitting idle, so it stays available for a campaign that does have budget.
Layers two and three are what protect deliverability, the metric that quietly decides whether email marketing works at all.
Delivery you can actually stop
Campaigns run in batches, and each batch records what it is about to do before it hands anything to the provider. That record is what makes pause and resume real: pausing sets a flag every batch checks before starting, and resuming picks up from the recorded position instead of restarting the campaign from the beginning.
Every send is keyed on the campaign-and-recipient pair. A retried batch that already sent will not send again. With two hundred thousand recipients, “try until it succeeds, but never repeat” is the only combination that ends well.
Concretely: spotting a broken link two minutes after launch costs a few hundred emails and an apology, rather than the entire list and a lost quarter of goodwill.
The feedback loop
The email provider streams bounces, opens, clicks and complaints back into the platform. Hard bounces suppress an address immediately; complaints suppress it and flag the list it came from. Delivery status pushes to the dashboard live, so a campaign in flight is something you watch rather than refresh.
This is list hygiene running automatically, and it compounds: clean lists keep deliverability high, which keeps future campaigns landing in inboxes. Automation sits on top - immediate, delayed and scheduled triggers - so a signup can start a welcome sequence with nobody in the loop.
The AI layer, and the boundary that makes it safe
This is the thesis part. Contact management is driven by natural language and voice: “add everyone who opened the March campaign to a new segment and tag them warm.”
The design decision that makes it safe to point at real customer data: the AI never writes to the database. It proposes a structured operation. The application validates that proposal, applies exactly the same permission checks a human request would face, and only then executes it.
A misunderstood instruction becomes a rejected proposal, not a corrupted contact list. That boundary is the whole difference between an AI feature a company can put in front of customers and a demo you would never point at real data. The argument in full: Let the Agent Propose, Not Write.
The result
- Nobody gets the same email twice, however many times a batch is retried.
- A campaign can be stopped mid-flight, turning a discovered mistake into a small one.
- Sender reputation is protected by design, which is what keeps future campaigns out of spam folders.
- Lists clean themselves from bounce and complaint signals, with no manual maintenance.
- Switching email provider is a settings change, so pricing and deliverability stay negotiable.
- Non-technical staff can manage contacts by talking, without anyone worrying the AI will delete something.
What it demonstrates
Careful backend work under a genuinely unforgiving constraint - actions that cannot be undone, at volume - with an AI layer treated as a proposer rather than an authority. It is the pattern I would use for any feature where a language model touches production data.