# Inkwave Case Study: Newsletter Platform Source: https://www.plutonapps.com/work/inkwave Published 2026-09-30, updated 2026-10-27. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). An all-in-one newsletter and publishing platform for creators, journalists and organizations: an editor, a website builder, subscribe forms, referrals, paid subscriptions, sponsorships and analytics in one dashboard. The founder brought it to us with a Lovable-built site that promised all of it. We built the platform that keeps those promises: one monorepo of fourteen apps and packages, newsletters that are never sent twice, every publisher on their own domain, and analytics without cookies. ## At a glance Inkwave is an all-in-one newsletter and publishing platform for creators, journalists and organizations: an editor, a website builder, growth tools, paid subscriptions and analytics in one dashboard. The founder brought it to Plutonapps with a Lovable-built site; our engineers built the platform underneath with the founder's team: 14 apps and packages guarded by 2,978 automated tests. Inkwave is pre-launch. - **Product:** Newsletter and publishing platform (B2B SaaS) - **Built in Lovable:** The public site: landing page, pricing and twenty feature pages - **Apps:** Publisher dashboard, public-site renderer, API, analytics, operator console, AI-assistant (MCP) server, migrator and two verification runners - **Stack:** React 19 · Vite · TanStack Router · Next.js 16 · Hono · GraphQL · PostgreSQL · Drizzle · ClickHouse · Restate · Clerk · Stripe Connect · Resend · Bun - **Timeline:** First commit May 2025 · one monorepo from July 2026 · 105 pull requests merged August 11 to September 29, 2026 - **Privacy:** Cookieless analytics, 18-month retention by table rule, per-publication cookie banner and consent settings, append-only audit log - **Status:** Pre-launch, deployed to staging on every merge Product site: [inkwave.space](https://www.inkwave.space) **2,978** Automated tests guarding the platform.. Up from 326 on August 6, 2026, days after the seven repositories came together in one monorepo: nine times the tests in eight weeks, across 280 test files and 105 merged pull requests. ## What did the founder bring from Lovable? The founder came with Inkwave's public face built in Lovable: a landing page, pricing, and a page for each of twenty platform features, from the editor and web builder to referrals, paid subscriptions and the ad network. Every page was a promise the product had to keep, and the code behind it had grown across seven separate repositories. Our job was to make it one platform that can be trusted with a publisher's audience and income. ## Why could it not go live as it was? A newsletter platform is judged on the day of a send. A retry that re-sends to a whole list, a custom domain that serves the wrong publisher, a save that overwrites a colleague's page or a missing check between two publishers' audiences is not a bug report, it is a lost customer. None of that is visible in a prototype, and all of it has to be engineered. ## Product decisions ### One dashboard for publishers Write and send newsletters, build the publication's website, grow the audience with forms, pop-ups and referrals, and earn from paid subscriptions and sponsorships, without switching tools. ### A site for every publication Each publication's website is rendered on its own domain from the published snapshot of the builder, never the draft. ### An operator console A cross-tenant console for the people who run the platform, with every operator action written to an append-only audit log. ## What did Plutonapps engineer? ### Every publisher on their own domain Risk in the prototype: A platform where every publisher brings a domain can be tricked into issuing certificates for domains nobody connected, or into serving one publisher's site under another's name. Before a certificate is issued, the edge asks the platform whether the domain belongs to a publication; the check fails closed and compares its shared secret in constant time. The site renderer maps each hostname to its publication and strips any identity header a visitor could forge. ### A website builder that cannot lose work Risk in the prototype: Two editors, or an editor and an AI assistant, saving the same page at once silently overwrite each other, and a half-finished draft leaks onto the live site. Every page's block tree carries a revision number, and a save made against an old revision is refused instead of merged blind. Live sites serve the published snapshot, never the draft, and an unpublished site answers 404. One shared block-schema package validates and repairs every block in the editor, the renderer and the API alike. ### Newsletters that go out exactly once Risk in the prototype: A send that dies halfway through a list and retries from the start emails thousands of readers twice. Each broadcast runs as a durable workflow on Restate, sent in batches of 100 recipients. Every batch is recorded as done exactly once, so a retry picks up where it stopped and never re-sends. Delivery webhooks are signature-checked, and a postal address is required before anything is sent. ### Analytics without cookies Risk in the prototype: Open and click counts are inflated by mail-privacy proxies and bots, and per-reader tracking cookies are a consent problem in every market. Events are batched into ClickHouse, flushed at 50 events or every three seconds, and visitors are counted with a hash salted per day, so no cookie is set and nobody can be followed from one day to the next. Apple Mail privacy and bot opens are separated from real ones, and activity data expires after 18 months by table rule, not by a job someone has to remember. ### Every write inside its own publication Risk in the prototype: In a multi-tenant product, one missing check lets a publisher read or change another publisher's audience. Sign-in moved from Firebase to Clerk, with tokens verified locally. Writes are scoped to the caller's publication in a shared service layer, and live-collaboration sockets re-check editing rights against the database on every connect. The AI-assistant (MCP) server never takes a publication from the request: the credential decides it, with consent and a budget on every write. ### Paid subscriptions that reconcile Risk in the prototype: Money moving between readers, publishers and the platform is where a missing webhook becomes a missing payment nobody notices. Publishers sell paid subscriptions through Stripe Connect while the platform bills publishers, and every Stripe webhook is signature-checked. Failed payments are stored, not logged and dropped, and refunds and subscription history are written from webhooks, so both sides keep an invoice trail. ## What were the results? - **2,978** Automated tests across 280 test files - **9×** The tests in eight weeks: 326 on August 6, 2026 - **105** Pull requests merged, August 11 to September 29, 2026 - **14** Apps and packages in one monorepo, from seven repositories - **100** PostgreSQL tables under versioned migrations - **15** End-to-end journeys run against a deployed environment ## Outcomes - 14 apps and packages in one Bun monorepo, brought together from seven repositories. - 2,978 automated tests across 280 files, up from 326 on August 6, 2026. - 105 pull requests merged between August 11 and September 29, 2026. - Pre-launch: deployed to staging on every merge while it is hardened. ## What do we hold ourselves to while it runs? - **Sending:** Durable batches of 100, never sent twice - **Tenancy:** Every write scoped to its own publication - **Own domains:** Certificates only after a fail-closed check - **Privacy:** Cookieless analytics and an append-only audit log ## What else do people ask about Inkwave? ### What is Inkwave? An all-in-one newsletter and publishing platform for creators, journalists and organizations: a newsletter editor, a website builder, subscribe forms, referrals, paid subscriptions, sponsorships and analytics in one dashboard. ### What was built in Lovable? Inkwave's public site: the landing page, pricing and a page for each of twenty platform features. The product itself is a TypeScript monorepo our engineers built with the founder's team. ### What did Plutonapps build for Inkwave? The platform underneath: newsletter sending that never goes out twice, publishers' own domains, a website builder that cannot lose work, cookieless analytics, tenant isolation, Stripe Connect payments and an AI-assistant server, in one monorepo of fourteen apps and packages. ### How is Inkwave tested? By 2,978 automated tests across 280 files, up from 326 in eight weeks, plus 15 end-to-end journeys and 11 liveness probes run against a deployed environment. ### Is Inkwave live? Not yet. Inkwave is pre-launch: every merge deploys to a staging environment while the platform is hardened for launch. ## Sources - [Inkwave's own site, inkwave.space](https://www.inkwave.space)