The founder version of the email problem
The founder version of the email problem looks like this: you have a Gmail Workspace or two, a domain or two, maybe an SES account that someone set up early, and you are trying to run cold outbound plus the occasional transactional email (password reset, customer onboarding note) without building out an entire email team.
Raw SMTP is the temptingly cheap answer. You already know how it works. You have credentials. Scripts can blast through SMTP at roughly the cost of the mailbox.
The less-obvious part: “raw SMTP” in production requires a lot of small things to be right at the same time. Per-mailbox caps so you do not trip Workspace limits. Suppression across every mailbox so an unsubscribe does not come back from a different sender tomorrow. Sequences that pause on reply signals. Audit trail so you can answer GDPR and security questions without guessing.
This article is about the founder trade-off: should you stay on raw SMTP and build those pieces, or put Mailers.io on top of your SMTP accounts and let the orchestration layer handle them?
Why founders default to SMTP and regret it
Founders default to SMTP for three honest reasons:
- It costs almost nothing. Workspace mailbox + script + DNS records = send. No platform bill.
- It is infinitely flexible. No policy, no vendor constraint.
- You already know it. Most founders with a technical background have written SMTP code at least once.
Founders regret SMTP for three other reasons, discovered in order:
- A mailbox gets flagged. One prospect flags you as spam, the reputation drops, and now the mailbox is half-useful. You realise you needed per-mailbox caps and rotation two weeks ago.
- A prospect asks to be removed. They unsubscribe from mailbox A. Two months later, a different mailbox ends up in the same sequence and you are back on their radar. You realise you needed a suppression table shared across senders.
- A buyer asks for an audit. A late-stage enterprise prospect asks, “who at your company has access to our data, and what is the retention policy?” You have scripts and spreadsheets. This is not a conversation you want to fake.
At this point the founder either writes the operating layer (and it is usually somewhere between a month and a quarter of engineering time) or adopts an orchestration layer that has it already.
What raw SMTP actually gives you
SMTP is a transport protocol (RFC 5321) for handing a message from sender to recipient. On its own, it gives you:
- A universal protocol supported by every mailbox and relay.
- Authenticated sending with SMTP AUTH over STARTTLS or TLS.
- A synchronous success/failure response (2xx / 4xx / 5xx).
It does not give you:
- Templates, variables, campaigns, sequences.
- Async events (opens, clicks, complaints, bounces that arrive after the fact).
- Suppression enforcement across mailboxes.
- Per-mailbox rate limiting, per-provider priority, failover.
- Team access, audit, RBAC, retention.
- Analytics, rollups, or anything a growth stakeholder would ask for.
What Mailers.io gives a small team
Mailers.io is an orchestration layer above any mix of SMTP servers and provider APIs. Connect your Workspace mailboxes, your SES or Mailgun account, your Outlook 365 inbox — it does not care. See /integrations for the list.
For a founder-led team, the useful parts are:
- Unified API. One endpoint for sending, regardless of which underlying mailbox or provider runs the send.
- Per-mailbox caps and rotation. Respect Workspace-level limits automatically; rotate across mailboxes by priority and remaining capacity.
- Campaigns and sequences. Run outbound sequences without writing cron logic.
- Suppression. One workspace-wide list that every connected mailbox respects.
- Audit and RBAC. Needed later than you think, but painful to retrofit.
- Free plan. 2,500 credits/month, one connected provider, no credit card. You can validate the setup before paying for anything.
What it does not do:
- It is not an email provider; you keep your SMTP providers.
- It does not manage replies or provide a unified inbox.
- It does not warm up inboxes.
- It does not provide leads.
- It does not guarantee inbox placement. Reputation, content, authentication, and receiver-side decisions are yours.
Side-by-side comparison
| Dimension | Mailers.io | Raw SMTP |
|---|---|---|
| Transport | SMTP + provider APIs underneath | SMTP |
| Campaigns / sequences | Built-in | None — you build |
| Per-mailbox caps | Native, configurable | You write code |
| Suppression across mailboxes | Workspace-wide | Per-mailbox unless you build a shared table |
| Audit log | Built-in | Log files |
| RBAC | Per-resource Full Access / Read Only | None |
| Failover | Automatic based on caps and errors | Custom logic |
| Cost to run | Orchestration plan + provider cost | Provider cost + engineering time |
| Reply management | Not provided | Not provided |
Three practical differences for founders
1. Time-to-value vs time-to-maintenance
Founders over-index on time-to-value and under-index on time-to-maintenance. Raw SMTP wins on day one. It loses slowly over the first quarter as small operational bugs compound. An orchestration layer is a slightly slower start and a much faster cruise.
2. Compliance credibility at the first enterprise deal
The first real enterprise customer will ask about suppression, retention, audit, and roles. If your answer is “we have it on our laptop in a spreadsheet,” the deal gets delayed. Mailers.io has the primitives already (workspace suppression, audit log, RBAC, a pre-signed DPA at /dpa) — not because it is fancy, but because those primitives are cheap to add to an orchestration layer and expensive to backfill into a script.
3. Swap-ability of the sending stack
If you code against SMTP directly today, moving to SES for volume or Postmark for transactional is a rewrite. If you code against an orchestration API, it is a workspace config change. For a founder who will probably rethink the stack twice in the first two years, this is non-trivial.
Three founder scenarios
Scenario A — Solo founder, 5 Workspace mailboxes
You are doing your own outbound. Five Workspace mailboxes, one domain, ~2,000 prospects a month across sequences. No engineering bandwidth to build an orchestration layer in-house.
Raw SMTP + a few scripts can work if you are disciplined about suppression and caps. Mailers.io’s free plan runs the same workload with the scaffolding already in place, which is generally the better use of your hours.
Scenario B — Founder + one engineer, 20 mailboxes
You have one technical teammate. Twenty mailboxes across three domains. Volume is climbing, bounces are climbing, and you realise you need structured sequence logic, centralised suppression, and probably an eventual failover path to SES for transactional.
Building all of that in-house is possible; it is also probably 4–8 weeks of engineering time. Orchestration compresses that to provider attachment and configuration.
Scenario C — Pre-enterprise founder closing a big deal
A serious prospect asks for DPA, RBAC, and an audit log during procurement. You are currently running scripts against SMTP.
Migrating during the deal cycle is stressful. Migrating before it is boring. A pre-deal decision to put your SMTP accounts behind an orchestration layer gives you the primitives to answer procurement questions without performing.
Pros and cons
When raw SMTP is right
- Extremely low volume and no plan to scale.
- You enjoy running infra and have the time.
- No enterprise sales in the near future.
- No regulatory or audit exposure.
When Mailers.io on top of SMTP is right
- You want the orchestration primitives without writing them.
- You are running multi-mailbox outbound or will be soon.
- Your next enterprise buyer is going to ask about suppression, retention, or audit.
- You want the option to add SES, Postmark, or another provider without rewriting code.
Who should choose what
Raw SMTP is right for toy volumes and infra-happy founders with no enterprise roadmap. Mailers.io is right for pretty much everyone else running real B2B outbound — especially before you hit the first real compliance conversation.
How to decide
A founder’s decision framework here is simple: multiply your number of mailboxes by your expected months of operation. If the answer is small, raw SMTP is honest. If it is large — and it usually is — the orchestration layer pays for itself in hours you will not spend debugging scripts.
The SMTP integration, quota-aware routing, and pricing pages are the concrete references if you want to see the exact mechanics.
When you operationalize Article at scale, the durable win is a repeatable review loop: weekly metrics that surface drift before leadership notices. That usually means bounces and complaints as first-class series—not vanity engagement charts—paired with a written rule for when a program pauses. This matters whether your stack is a single console or a multi-provider layer; the work is the same even when “Article” is the public label on the project.
Cross-functional alignment fails quietly: Marketing ships a new domain, Data updates a list export, and Engineering rotates an API key—each change reasonable alone, but together they break assumptions about identity and suppression. A useful discipline is a lightweight change log for anything that touches a live sending identity, even if the change is “small.” The goal is not paperwork theatre; the goal is that the next on-call can reconstruct state without heroics.
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.
Runbooks are underrated. A good runbook is not a PDF nobody opens; it is a checklist that includes who is allowed to do what, what “pause sending” does in your configuration, and how to verify suppression state after an incident. Mailers.io is built as orchestration and policy on infrastructure you connect—useful when you have multiple paths, shared templates, and need consistent governance across teams. It is the wrong product if the primary pain is a missing CRM surface or a guarantee that mail will “land in primary.”
Finally, treat deliverability talk as a constraint problem, not a battle of slogans. Recipients, mailbox providers, and local IT policies are not under your vendor’s control. What you can control is list provenance, authentication, throttles, content hygiene, and how fast you stop repeating mistakes. The organizations that do well here look boring: fewer surprises, fewer “unknown unknowns” in audits, and operators who can show receipts.
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.
Procurement and security questions often ask for certifications as shorthand. The better question is: what logs exist, for how long, and who can access them? A control plane can unify routing, but you still need your own data map for personal data, subprocessors, and incident response. This article is educational; align final commitments with your counsel and your customer contracts. We do not claim outcomes we cannot own (placement, read rates, or a unified sales inbox) because that would mis-sell the product’s shape.
Testing discipline for guide-style problems usually improves when you separate “content experiments” from “infrastructure changes.” If you must change both, sequence them: stabilize the path, then test creative, or you will not know which variable moved the signal you care about. If you are comparing providers, do it with the same list ethics and the same segment definitions; otherwise the comparison is a story, not a measurement.
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.