How to Build an App Like Substack: Newsletter Platform Architecture

Substack takes 10% of every dollar your paid subscribers send you. A newsletter at $20,000/month in subscription revenue sends Substack $2,000 every single month. At $100,000/month, that's $10,000 gone before you pay a writer or a server bill. The platform gets more valuable as you grow, but so does the cost of staying on it.

The businesses that build their own newsletter infrastructure are not doing it to avoid a small fee. They are doing it because owning the subscriber list, the sending domain, the billing relationship, and the product experience is worth more than the engineering cost. Here is how the platform actually works.

Who builds this instead of using Substack

Not every newsletter needs custom infrastructure. Substack is a good product. But there are specific cases where owning the platform beats renting it.

Media companies with existing brands cannot afford Substack's footer, which links readers to the Substack homepage and surfaces competing newsletters. They need the infrastructure to run under their own domain with no traces of the underlying platform.

B2B publishers, content-led brands in legal tech, healthcare, and finance, and professional associations often need subscriber segmentation that Substack does not provide. Segment by job title, company size, or account type and you can send different content to different tiers. Substack handles free versus paid. That is about it.

Corporate L&D teams build internal newsletter platforms to push weekly training content to employees without routing that content through an external SaaS that stores employee data. GDPR and internal data governance make this a real constraint.

Agencies building publishing products for clients need white-label infrastructure. Spinning up a Substack for each client does not scale and leaves every client dependent on a platform the agency does not control.

The publishing editor

The core product is the writing experience. Two open-source editors dominate this space: Tiptap and Lexical.

Tiptap is built on ProseMirror and has a large extension ecosystem. You get headings, bold, italic, code blocks, image embeds, video embeds, audio, and custom blocks out of the box. The extension API makes it straightforward to add newsletter-specific blocks: paid content dividers, subscriber-only sections, embedded tweets, and custom CTAs.

Lexical comes from Meta. It is more performant at large document sizes and has a cleaner plugin architecture, but its ecosystem is smaller and the documentation is thinner than Tiptap's.

For a newsletter platform, Tiptap is the safer choice. The extension library handles 90% of what you need without custom development.

Beyond the editor, the publishing flow needs draft saving every 30 seconds (auto-save to the database, not just localStorage), a preview mode that renders the email template exactly as subscribers will see it, and scheduling. Scheduling sounds simple: pick a date and time, and the system sends. The complication is timezone handling. A New York-based writer scheduling for "9 AM" needs the system to send at 9 AM Eastern. Store publish times in UTC in the database, display in the writer's local timezone in the editor.

Subscriber management

Every newsletter platform has the same core data model: a subscriber record with an email address, a status (active, unsubscribed, bounced), a tier (free or paid), and metadata like signup date and source.

The details that take time to build properly are the ones most teams underestimate.

Subscriber import from Mailchimp and ConvertKit is a day-one requirement for any publisher switching platforms. They have tens of thousands of subscribers they are not willing to lose. The import flow reads a CSV, validates email addresses, deduplicates against existing records, and triggers a welcome email or silently adds them depending on the import settings. Doing this wrong means duplicate sends or missing subscribers, which destroys trust fast.

GDPR-compliant unsubscribe is not just a link at the bottom of an email. It is a one-click process: click the link, you are out, no confirmation screen asking if you are sure. The database record updates immediately. You cannot re-add that subscriber without their consent. Unsubscribe links must be unique per subscriber so you know exactly who unsubscribed.

Segmentation by tier (free, paid, gifted, comped) lets the publisher send different emails to different groups. Paid subscribers get the full version. Free subscribers get a truncated version with an upgrade CTA. This is the core monetization mechanic.

Email delivery: the infrastructure that actually matters

Most newsletter platforms ship a beautiful editor and a broken email delivery system. Deliverability is invisible until it fails, and when it fails, open rates drop 40% overnight because emails are landing in spam.

Two services handle transactional and newsletter-scale email: Amazon SES and SendGrid.

Amazon SES costs $0.10 per 1,000 emails. At 100,000 monthly sends, that is $10. At 1,000,000 sends, that is $100. No other service comes close on price at volume. The tradeoff: SES requires more configuration and provides less support if you have deliverability problems.

SendGrid costs more but has better deliverability tooling: real-time analytics on bounces and spam reports, automatic suppression list management, and dedicated IP pools for newsletter sends. For a platform in its first year, SendGrid's dashboards will save you days of debugging.

Whichever service you use, the sending domain configuration is non-negotiable.

Your newsletters cannot go out from a generic SES or SendGrid address. They need to go out from newsletter@yourdomain.com or a subdomain like send.yourdomain.com. That custom sending domain requires three DNS records that prove you are who you say you are: SPF, DKIM, and DMARC.

SPF is a TXT record that lists the mail servers authorized to send on behalf of your domain. DKIM adds a cryptographic signature to every email that receiving servers verify against a public key in your DNS. DMARC tells receiving servers what to do when SPF or DKIM checks fail: quarantine the message, reject it, or allow it through.

Gmail and Yahoo tightened their sender requirements in 2024. Without all three records configured correctly, your newsletters will land in spam for a significant share of subscribers. This is not a theoretical problem. It is the reason newsletter platforms fail.

Both SES and SendGrid provide step-by-step guides for setting up these records. The process takes a few hours and requires access to your DNS provider (Cloudflare, Route 53, GoDaddy, wherever your domain is registered).

Paid subscriptions with Stripe

Stripe is the right tool for newsletter subscription billing. It handles monthly and annual plans, upgrade and downgrade mid-cycle, failed payment retry logic, and webhook events that tell your application what is happening.

The data model at the Stripe level: you create a Product for your newsletter, then create two Prices under that product, one for the monthly plan and one for the annual plan. When a subscriber upgrades, you create a Stripe Subscription linking their Customer record to one of those Prices. Stripe handles billing on the anniversary date, sends receipts, and fires webhooks when anything changes.

The events your application needs to handle:

customer.subscription.created unlocks paid content for the subscriber. customer.subscription.deleted removes paid access. invoice.payment_failed triggers your dunning sequence: email the subscriber asking them to update their payment method. Stripe retries the charge automatically on a schedule you configure (typically day 1, day 3, day 7). If the card still fails after the final retry, the subscription cancels.

Gifted subscriptions let readers buy a paid subscription for someone else. The gift recipient gets a redemption link. Comped subscriptions let the publisher give free paid access to guests, journalists, or reviewers without charging them. Both are Stripe-supported via coupon codes that set the subscription price to zero for a defined period.

Public archive and SEO

Every published newsletter issue gets a public web page. The URL structure is typically yourdomain.com/p/post-slug. These pages are indexed by Google and serve two purposes: they let non-subscribers discover your content through search, and they give subscribers a web version to read when the email client renders poorly.

Each post page needs an Open Graph image for social sharing, a subscribe CTA, and proper canonical tags so Google does not treat the email version and the web version as duplicate content.

The archive page lists all published issues with titles, dates, and excerpts. For newsletters that have been publishing for years, this archive becomes a real SEO asset.

Podcast and audio hosting

Substack's audio feature lets writers host podcast episodes alongside newsletter issues. The technical layer is RSS feed generation.

When a newsletter includes an audio file, the platform stores it on S3 and serves it through CloudFront (Amazon's CDN). The RSS feed lists all audio episodes with title, description, duration, and the S3/CloudFront URL. Podcast directories like Apple Podcasts and Spotify consume this RSS feed to populate the show in their apps.

This is optional infrastructure for your MVP. Build it only if audio content is a primary use case for your early publishers.

Analytics

Five metrics drive every newsletter business decision: open rate, click rate, subscriber growth (net, not gross), paid conversion rate from free to paid, and monthly churn rate on paid subscribers.

Open rate and click rate come from tracking pixels embedded in the email (a 1x1 transparent image that fires a request to your server when the email loads) and tracked links that redirect through your server before hitting the destination URL. Apple's Mail Privacy Protection has made open rates less reliable since 2021, but they remain a useful directional metric.

Subscriber growth, paid conversion, and churn live in your database. A simple analytics dashboard showing these five numbers over a 90-day rolling window covers most of what a publisher needs.

Tech stack

The core stack for a newsletter platform is straightforward:

Editor and reader: React. The writing interface and the subscriber-facing reader are both React applications. The editor is a single-page app. The reader can be server-rendered Next.js for SEO.

Backend: Node.js with a REST API. Newsletter platforms are not computationally heavy on the API layer. The load comes from email sends, which are async and handled by the email delivery service, not your API.

Database: PostgreSQL. Subscriber records, posts, subscription states, analytics events. Standard relational data with predictable query patterns.

Email delivery: Amazon SES or SendGrid, as discussed.

Payments: Stripe.

File storage: AWS S3 for images, audio files, and email attachments. CloudFront as the CDN layer in front of S3.

RSS generation: A library like feed (Node.js) generates valid RSS and Atom feeds for podcast directories.

Timeline and cost

MVP timeline: 8-10 weeks. This covers the publishing editor, subscriber management, email delivery, Stripe integration, public archive, and basic analytics. Podcast hosting adds 2 weeks.

MVP cost: $80,000-$120,000. The range depends on team location, complexity of the editor extensions needed, and whether you need a mobile reading experience in addition to the web reader.

Running infrastructure cost: $2,000-$5,000/month at scale. This breaks down as: SES or SendGrid email costs (volume-dependent), Stripe fees (2.9% + $0.30 per transaction), AWS S3 and CloudFront (storage and bandwidth), and server costs for the API and database.

At $20,000/month in subscription revenue, the platform pays for itself in under six months compared to Substack's 10% cut. At $100,000/month, the break-even is under two months.

What teams get wrong

The editor gets over-engineered. Teams spend four weeks building a custom rich-text editor from scratch when Tiptap handles 95% of use cases in a week. Use the library.

Email deliverability gets left to the end. It needs to be set up on day one. Your sending domain, SPF, DKIM, and DMARC records should be configured before you send a single test email. Trying to fix deliverability problems after you have sent to 50,000 subscribers is much harder than configuring it correctly upfront.

Subscriber import gets underestimated. Publishers switching from Mailchimp or ConvertKit will not do it without a reliable import tool. A broken import (duplicates, missing subscribers, failed validation) is a launch blocker. Treat it as a first-class feature, not an afterthought.

The one thing that separates a working newsletter platform from a broken one is email delivery. Get that right and everything else is a product problem you can iterate on.