# Pluma

> Pluma is a multi-publication operating system for independent media, agencies and author networks.

Source page: https://saascode.ai/products/pluma
Machine-readable record: https://saascode.ai/products/pluma.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $249 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

Pluma runs many independent publications on one installation. Each publication is an organization: it gets its own branded reading site, its own writers, its own subscriber list, its own newsletter and its own paid memberships. Nothing crosses between publications.

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/pluma — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://pluma.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

6 roles seeded on the demo (of the 7 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Invited author** (`contributor`) — `contributor@demo.com` / `demo123`
  Creates and revises personal drafts for editorial review.
- **Publication editor** (`editor`) — `editor@demo.com` / `demo123`
  Edits, schedules and publishes the publication's articles.
- **Publication owner** (`org_admin`) — `org-admin@demo.com` / `demo123`
  Manages content, members, staff, pricing and publication settings.
- **Reader** (`reader`) — `reader@demo.com` / `demo123`
  Manages memberships, comments and email preferences.
- **Platform support** (`admin`) — `staff@demo.com` / `demo123`
  Handles publication support, moderation and platform billing.
- **Platform owner** (`super_admin`) — `admin@demo.com` / `demo123`
  Runs every publication, plan, integration and platform control.

Or open a role directly: https://saascode.ai/demo/pluma?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 7** — distinct roles accepted by the role CHECK constraint: admin, contributor, editor, member, org_admin, reader, super_admin
- **tables: 89** — distinct CREATE TABLE statements across every applied migration
- **migrations: 117** — .sql files in supabase/migrations
- **page modules: 126** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 218,617** — lines of code (comments and blank lines excluded) across 1453 TypeScript files (191,801) and 156 SQL files (26,816); node_modules and .next excluded
- **api route files: 273** — files named route.ts under src/app/api
- **http operations: 379** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 89 tables, 157 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0 · built 2026-08-23

## Complete capability inventory

13 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### Platform operations

- **Connect API** *(seller-authored)* — A scoped workflow API sits behind the Connect feature flag and the Scale plan as configured. The buyer inherits a server-gated extension for their publication customers, with API-key scope controlling access instead of a separate SaaSCode add-on.
- **Additional languages** *(seller-authored)* — Additional interface languages sit behind the shipped language flag and a Publisher-or-higher plan as configured. The buyer receives the gated translation surface and controls which publication customers inherit access through their own plan ladder.

### Editorial workflow

- **Publication authoring** — An article is written in blocks: text, image, quote, code and approved embeds. Drafts autosave, every save keeps a revision, and any revision can be previewed before it goes out.
- **Member comments** — Comments are membership-gated by design: the publication decides which tiers may comment, and the owner moderates. This is a reply channel under an article, not a general forum.

### Audience & revenue

- **Reader memberships** — A subscriber does not need an account. Participation is keyed on the publication plus the normalized email address, with an optional link to an account. Someone can subscribe with only an email, receive the newsletter, use the one-click unsubscribe link and open a tokenized preferences page, all without ever signing in. If they later create an account and verify that address, the existing subscriptions are adopted into it. Nothing is duplicated and nothing is lost.
- **Advanced segments** *(seller-authored)* — Publication staff build audiences from membership tier, tags, tenure, and privacy-aware behavior. Advanced segments ship behind Publisher or higher as configured, so the buyer inherits a paid-plan capability that can target campaigns without exposing audience data across publications.
- **CSV export** *(seller-authored)* — Publication staff can export audience records within their own publication boundary. The shipped flag is available across the configured plans, while the publication-scoped guard keeps one publication's subscriber data out of every other publication's export.

### Campaign delivery

- **Campaign sending** — Plan limits are enforced before queue admission and they fail closed. A campaign that would exceed the monthly send allowance is refused whole, never partially sent, and the publication owner is pointed at billing.
- **Campaign analytics** — Delivery, bounce and complaint counts come from provider webhooks and are real as soon as sending is live.

### Publication reach

- **Publication templates** — A publication chooses how its public site looks from a catalog of runtime templates. These are the publication's themes, chosen by the publication owner, and they are entirely separate from the look of the Pluma application itself.
- **Custom domains** — Every publication always has a working address on this installation's own hostname, at /p/{publication-slug}. That fallback never goes away.
- **Full template catalog** — Which templates a publication may use depends on its plan: the Launch plan gets the starter set, Publisher and Scale get the full catalog. New validated templates can be added over time.
- **Recommendation network** — A publication can recommend other publications on the same installation, with consent on both sides, and the source of a resulting subscription is attributed. The platform owner governs which recommendations are allowed. This is available on the Scale plan.

## What each system gives the operator

*stated.*

- **Platform operations** — Run distinct publication businesses from one controlled installation.
- **Editorial workflow** — Keep every live edition stable while the next revision moves forward.
- **Audience & revenue** — Grow paid readership without mixing identities, entitlements, or publication revenue.
- **Campaign delivery** — Turn frozen audiences into accountable sends without partial campaign surprises.
- **Publication reach** — Give each publication a branded destination that survives provider delays.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### The live edition stays dependable while the newsroom keeps moving.

Publishing teams rarely stop editing just because an edition is already live. Without a clear boundary between current work and what readers can see, a small correction becomes a risky event: someone overwrites the wrong version, a scheduled story exposes an unfinished change, or the archive no longer matches what subscribers received. The cost is editorial hesitation. Writers wait for a safer moment, editors duplicate documents to protect themselves, and readers lose confidence when a link changes beneath them. A publication business needs speed without turning every revision into a gamble with its public record.

### Each publication grows reader revenue without surrendering the relationship.

When audience identity, access and money are collapsed into one shared account system, ordinary support work becomes a reconciliation exercise. A reader appears twice, a lapsed entitlement still opens paid work, or one publication can see activity that belongs to another. Those mistakes do more than waste time: they make every new title harder to trust and every billing dispute harder to explain. Independent publications need to grow memberships on the same installation while keeping their audiences, revenue decisions and staff boundaries legible. Otherwise the platform operator becomes the manual bridge between businesses that were supposed to remain independent.

### Large sends remain deliberate while the audience changes underneath them.

A newsletter deadline compresses editorial, audience and delivery decisions into a few minutes. If those decisions remain fluid after a send begins, teams cannot explain who received what, stop a mistaken campaign cleanly, or distinguish an unsubscribed reader from a delivery failure. The visible damage is a bad email; the lasting cost is uncertainty around every future send. Publication owners need campaign work to remain understandable under pressure, with limits and audience choices that fail predictably instead of producing a half-finished blast and a cleanup project.

### Every publication can look independent without becoming a separate deployment.

Agencies and author networks outgrow a single branded site quickly, but a separate installation for every title turns growth into infrastructure work. Design changes drift, domains fail in different ways, reporting fragments, and the team spends more time reconciling environments than improving the publications. The opposite extreme, a single generic skin, makes every title feel interchangeable and weakens the trust each audience formed with its own publication. The operating challenge is to give each publication a distinct, durable presence while keeping ownership and maintenance coherent for the business that runs them all.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node host** (required) — Next 16.2.10 and React 19.2.3.
- **Supabase** (required) — The shipped application uses Supabase.
- **Scheduled job runner** (required) — Four jobs are declared in `vercel.json`; another host needs an equivalent scheduler.
- **Email provider** (optional) — Provider modules are present for Brevo, Mailgun, Resend, SendGrid and SMTP; configure one for outbound email.
- **Upstash** (optional) — An optional service exposed by the shipped environment contract.
- **Sentry** (optional) — An optional service exposed by the shipped environment contract.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 218,617 lines across the application and its database, 89 tables defined by 117 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Pluma demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 6 of them: Invited author, Publication editor, Publication owner, Reader, Platform support, Platform owner. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 126 page modules and 379 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node host, Supabase, Scheduled job runner. Optional: Email provider, Upstash, Sentry. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 117 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $249?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Multi-publication platforms in 2026: where does the second publication live?](https://saascode.ai/inside/multi-publication-platforms-2026-second-publication.md)
- [Pluma: a multi-publication operating system for independent media](https://saascode.ai/inside/pluma-multi-publication-operating-system-independent-media.md)
- [Pluma vs beehiiv: source-owned platform or managed publication workspace](https://saascode.ai/inside/pluma-vs-beehiiv-source-owned-platform-managed-workspace.md)

## Links

- Catalog page: https://saascode.ai/products/pluma
- Product record: https://saascode.ai/inside/products/pluma
- Live demo: https://pluma.saascode.ai
- Every product: https://saascode.ai/llms.txt