Why we built SendBeam around one account for every site you run

We run five websites. None of them is big. There is a UK salary calculator, a UK house-price site, a directory of UK companies, a site of small image tools and a bidding SaaS used by a handful of businesses. Between them they have contact forms, newsletter signups, three weekly newsletters generated from live data, and the usual transactional email a SaaS needs: sign-in links, invoices, “your bid was accepted”.

That is not an unusual situation. Plenty of people run a portfolio of small sites: a freelancer with three client-facing brands, a developer with two side projects and a blog, a local business with a shop and a separate site for its trade customers. Every one of those sites needs email, and every one of them is too small to justify its own email budget.

SendBeam exists because the tools we tried were shaped for one brand with one list. This post is about what that shape cost us, and which decisions we made differently. It is the positioning post, so it is opinionated, but every claim about the product is something you can check in the docs.

What five sites’ email looks like on ordinary tools

Most email platforms are built around one identity. On some it is called an audience, on others a publication or a creator account. The name varies; the consequence does not. A second site means a second one of those, and a second one of those is either a second bill or a second account.

Here is what that turned into for us.

Five logins. Five dashboards, five sets of API keys, five webhook formats to handle bounces, five places to check when something looked wrong. When anything looks wrong, the first job is working out which account it happened in.

Costs that multiply instead of add. Per-audience billing means the price of email is roughly the price of one list times the number of sites, even when each list is tiny. A thousand contacts is a rounding error for any platform. Three lots of a thousand contacts, billed separately, is a real monthly cost. We have laid out the numbers platform by platform in what Mailchimp, Kit, beehiiv, MailerLite and EmailOctopus cost when you run three sites; the short version is that most of them charge you three times for what is, from your point of view, one small audience. You can check the two we quote most often yourself: Mailchimp’s pricing counts every contact in every audience, and Kit’s is one list per account.

Authentication set up five times, five different ways. Every domain needs its own DKIM keys and an aligned return path so that Gmail, Yahoo and Microsoft trust the mail. That part is unavoidable and correct. What is avoidable is doing it in five dashboards that each hand you a slightly different set of records, some as CNAMEs, some as TXT, some with a shared return path you cannot align to your own domain. DMARC, which you publish once per domain, then has to be checked against five different sending set-ups.

Suppression lists that never meet. When someone’s address bounces on one tool, the other four keep trying. When someone unsubscribes from a newsletter, the transactional tool for the same site has no idea. And when you move a list between tools, the unsubscribes are the thing most likely to get left behind, which is precisely the thing you must not leave behind.

Automation glued together by hand. Three of our newsletters are built from data. The house-price site emails each subscriber the sold prices in their own district when the Land Registry publishes a new month; the companies directory sends a weekly digest of newly incorporated companies; the salary site sends a weekly issue of pay and tax news. Each of those is a script that assembles an issue and calls an API. Five different SDKs and five different rate limits is a lot of surface area for what should be one job.

None of these problems is dramatic. Together they are the reason small sites end up with no email at all, or with a contact form that goes to a personal inbox and a newsletter that was going to launch next quarter for the last three years.

The shape we wanted

We wanted one account, one login, one bill, and inside it a clean separation per site. Not one giant list with tags for each site: that muddles consent, muddles reporting and means a mistake on one site is visible to subscribers of another. Each site should have its own contacts, its own lists, its own forms, its own automations, its own sending domain and its own team seats, while the plan and the money sit above all of them.

That is what a SendBeam account and its workspaces are. The account is the billed unit. Workspaces are the sites. Contacts and monthly emails pool across the account, so a site with 300 subscribers and a site with 3,000 share one allowance instead of each buying its own.

The decisions that followed

Once you commit to that shape, a number of product decisions make themselves.

Pooled plans, priced by contacts and never by domain

There are four plans: Free at $0, Starter at $9, Pro at $29 and Business at $79 a month. They are priced on total contacts across the account (500, 2,500, 10,000 and 50,000) and monthly emails (2,000, 15,000, 60,000 and 250,000). Free is two workspaces, Starter is five, and Pro and Business have no limit on workspaces. Adding a site never adds to the bill; only growing your audience does. The full table is on the pricing page, and we do not intend to add a per-domain or per-workspace charge later.

One workspace per site, and separation on purpose

A workspace is a hard boundary. Its contacts, suppression list, forms and domains belong to it alone. The obvious question is whether unsubscribes should sync across workspaces, and our answer is no: someone who unsubscribes from the house-price newsletter has not unsubscribed from the salary newsletter, because those are two different consents given on two different sites. Treating them as one would be wrong in law and rude in practice.

We should be equally clear about what that means in the other direction. A hard bounce recorded in one workspace does not currently suppress the same address in your other workspaces. That is a gap we know about and may close with an account-wide bounce list that you can switch on; complaints and unsubscribes will stay per site.

Delivery that is managed, not configured

You do not connect a delivery provider or paste an API key. Every workspace can send immediately from a shared platform address, and when you add your own domain, SendBeam shows you the CNAME records for DKIM signing and an aligned return path. If your DNS is on Cloudflare, it writes them for you from a one-time token. Bounces and complaints are handled automatically, every campaign and automation email carries an RFC 8058 one-click unsubscribe header, and there are guardrails that warn and then pause sending if complaint or bounce rates climb, so a bad import cannot quietly ruin the reputation of your other sites. The details are in the deliverability post.

Forms that do the two jobs small sites actually need

Two kinds of form: a signup form that creates a contact, with double opt-in available per list and compulsory on the Free plan, and a contact form that emails you the message with the visitor as reply-to and never creates a contact. Filling in a contact form is not subscribing, and the product should not pretend otherwise. Both kinds have an origin allow-list, rate limits and optional Cloudflare Turnstile.

An API and a scheduler, because newsletters from data are normal

Reads and writes through the API are on every plan; writes are metered per hour rather than gated. That is what lets a script assemble this week’s issue from live data and hand it to a template. There is nothing special about our five sites here. If you publish anything that changes weekly, you can do the same.

Move-in, because the hardest part is leaving

Most people who want this shape already have email running somewhere else, often in several places. Move-in is a migration service: suppressions go across first, then subscribers with whatever consent evidence your old platform kept, then forms and domains, then a parallel run, and unsubscribes on the old platform are synced for 30 days after cutover. It is included on Pro and Business. Contacts with no consent evidence at all are left out rather than emailed, and you are told who they were.

What SendBeam does not do

Positioning is as much about what you leave out.

• No ad network. We do not sell ads into your newsletter or take a cut of sponsorships.
• No paid subscriptions. There is no built-in paywall or reader billing. If your newsletter is the product and you want to charge for it, Substack or beehiiv will serve you better, and we say so on the alternatives pages.
• No SMS. Email only.
• No website hosting or landing-page builder. You bring the site; we handle the email.
• No bring-your-own delivery keys. Delivery is platform-managed for everyone, which is how the guardrails and the deliverability defaults can be guaranteed.

If any of those is essential to you, we are the wrong choice, and it is better to know that now than after a migration.

What this blog is for

We are going to write about running email for small sites, honestly. That means the actual prices other platforms charge, checked on a stated date; what the mailbox providers now require and how to see whether you meet it; what UK law says about consent and about changing provider; and what we learn from sending three data-driven newsletters a week from our own sites. It will not become a list of subject-line tips.

If you run more than one site and email has been the thing you keep putting off, the Free plan covers 500 contacts and two workspaces, and Starter gives you five workspaces for $9 a month. Start with the site that most needs it.