May 13, 2026

Inside News — the anatomy of a newsletter made of items, issues and sends

Inside News

It is easy to look at a newsletter product and see a box where you write an email and click "send to the list." Most tools really are that box. LaunchWithAgency's News product is not — and the difference isn't in the interface, it is in the data model.

News separates five concepts that simpler tools collapse into one: the list, the subscriber, the item, the issue and the send. This article walks through all five, explains why each is its own entity, and shows how that separation turns a newsletter from a text box into an editorial system.

The list: the channel

A list (newsletter_lists) is the channel — the "Tech Weekly," the "Product Updates." It has a name, a description, a sender (fromEmail, fromName) and a language. You can have several lists: one per audience, one per language, one per client if you are an agency.

Two schema details say a lot about the philosophy. First, the list's slug is unique per owner, not globally — two platform users can each have a list named growth, because the public URL is qualified by the owner's handle. Second, there is the publicArchive flag: a list may, or may not, expose its past issues as public web pages. A newsletter isn't only an email that evaporates in the inbox — it can be a browsable archive.

The subscriber: a row that has state

A subscriber (newsletter_subscribers) belongs to a list and — this is the point — has state. The status column carries pending, active or unsub. The confirmedAt column marks when they confirmed; unsubscribedAt, when they left. There is also source, recording where they came from, and locale, their language.

That state is what makes double opt-in a property of the data, not a separate feature. When someone subscribes, a pending row is born. The Emails product fires a confirmation email. Only when the person clicks the link does the row become active and gain a confirmedAt. A pending subscriber is not a real subscriber yet — and the schema knows it. Nobody is included in a send without having verifiably said yes.

> A subscriber isn't an email address on a list. It is a record with a lifecycle — pending, active, unsubscribed — and every transition is recorded.

The item: the curated unit

Here is the entity that separates News from a text box. An item (newsletter_items) is a small, curated unit of content: a link, an idea, a short note. It has a title, an optional URL, a body in Markdown.

Why is this its own entity? Because curating a newsletter doesn't happen all at once, at the moment of writing the issue. It happens over the week — you find a link on Tuesday, jot down an idea on Thursday. The item has its own status: unassigned, while it sits in your collection, and in_issue, once it belongs to an issue. News gives you a collection of items you gather at your own pace, and from which you assemble the issue later.

The issue: the email that goes out

An issue (newsletter_issues) is the concrete email that goes to the list — "Issue #42." It has a title, a slug, and two fields that wrap the items: introMd and outroMd, the opening and closing that frame the curation.

The relationship between issue and items is where the model shines. It isn't a copy — it is a junction table, newsletter_issue_items, that links an issue to its items with a position, defining the order. That means an item is reusable, that the issue's order is editable without rewriting anything, and that assembling an issue is organizing items, not typing an email from scratch. The issue also has state: draft, scheduled, sent — and when sent, it records sentAt and sentCount.

The send: the per-recipient record

The fifth entity is the most granular. A send (newsletter_sends) is one row per recipient, per issue. When Issue #42 goes out to 800 subscribers, 800 rows are born in newsletter_sends — each with the subscriber, the status, and the openedAt and clickedAt fields.

That is what turns "I sent the newsletter" into data. You don't have a loose aggregate number; you have the individual record of each send, from which issue to which subscriber, with what happened afterward. It is the base on which any honest engagement metric is built.

Why separating five concepts is the product

Add up the five entities and notice what you have: a list that is a real channel with a public archive; subscribers with a lifecycle and verifiable opt-in; a collection of items you curated over time; issues that are organized items, not rewritten text; and a per-recipient send log.

That isn't a "write and send" box. It is an editorial system. And it is deliberately the "basics done well" — News doesn't try to be a giant marketing automation platform. It does what a newsletter needs, with a data model that respects how curation actually works, without the overhead of a dedicated tool.

And, like everything in LaunchWithAgency, it lives in the same database as the other four products. The News subscriber is the same row as the lead captured in Pages. The issue that was sent leaves a trail in the same place Flows can read. The newsletter isn't an island — it is one of the five faces of the same system.