Pluma
Pluma is a multi-publication operating system for independent media, agencies and author networks.
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.
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.
- Publication authoring
- Member comments
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.
- Reader memberships
- Advanced segments
- CSV export
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.
- Campaign sending
- Campaign analytics
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.
- Publication templates
- Full template catalog
- Custom domains
- Recommendation network
- Additional languages
Publishing creates an immutable snapshot. When an article is published, the exact revision is frozen into a snapshot and the publication's active pointer switches to it, both inside one transaction. The public site, the archive, search and email all read the active snapshot and never read a draft. That is why an edit after publishing does not silently change what a reader already sees: it becomes a new revision, and publishing again creates a new snapshot.
Scheduling works the same way, just with the switch deferred to the scheduled time.
Each article carries an access policy, evaluated on the server against the snapshot:
Because it is evaluated server-side, a paid article's body is not sent to a browser that is not entitled to it. Archive search behaves the same: it only indexes active snapshots, and it filters paid results by the reader's current entitlement, so search can never leak a paywalled body.
Articles are organized by sections (the publication's own top-level structure), tags (free-form) and authors (each with a public author page). All three are per publication.
Where to work:
Paid membership tiers are defined per publication. The seeded defaults are Free Reader at $0, Member at $8 per month or $80 per year, and Patron at $15 per month or $150 per year. A publication owner can rename, reprice or disable any paid tier.
The membership lifecycle covers checkout, activation, mid-period upgrade and downgrade, dunning grace when a payment fails, cancel-at-period-end, refunds and reconciliation from provider events. Alongside paid subscriptions, staff can grant a membership directly as a trial, a complimentary grant, a gift, a prepaid grant or a manual grant. Those grants carry no provider subscription and are as valid as a paid one.
Audience operations available to publication staff:
Readers manage their own side from the reader portal: their memberships across every publication they follow, their payment method through the publication's provider portal, cancellation, and email preferences.
Sending requires configuration before it works.
Pluma ships a complete Mailgun adapter, but it reports not configured until an API key is supplied. Until then the queue stays disabled. Everything else keeps working: articles publish, the public site serves, memberships are bought and read. Only sending waits.
To enable it, add the Mailgun API key and region under integrations, point the bounce, complaint and delivery webhooks at this installation, then authenticate at least one sending domain for the publication. Sending stays off until a publication has an authenticated sending domain of its own.
An Amazon SES option is present in the adapter list but its transport is not installed, and selecting it reports that plainly rather than silently falling back to Mailgun. That is deliberate: switching transport in the middle of a send would duplicate deliveries. Choosing SES is an explicit setup decision with an owner responsible for reputation, sandbox exit and warm-up.
Open and click figures are treated with more care. Where a metric has not actually been measured, the interface says not measured rather than showing a plausible-looking zero percent. A zero that means "nothing was tracked" and a zero that means "nobody clicked" are different answers, and Pluma will not print them the same way. Open tracking in particular is labeled unreliable wherever mail privacy features inflate it.
Templates are versioned, and a version is validated before it can be activated. Activating one is a compare-and-swap on the publication's assignment, so switching template never edits the template itself and never touches published content. Template markup renders in a sandboxed frame without same-origin access, so a template cannot reach into the surrounding application.
A custom domain is layered on top and is asynchronous by design. Ownership verification and certificate issuance are handled by a managed hostname provider, with Cloudflare for SaaS as the default. While verification is in flight, while it fails, or if the provider is unreachable, the fallback address stays live and the last published snapshot keeps serving. Hostname uniqueness is enforced by the database, so two publications cannot claim the same host.
Like sending, this needs credentials before it does anything. The Cloudflare adapter is complete and reports not configured until a zone, an API token with hostname permissions and a fallback origin are supplied. Custom domains are unavailable until then, and every publication still reads fine on its fallback address.
The platform underneath the product — counted in this product's own source, not claimed from a template. Where a row carries a list, open it to read the names behind the number.
Coinbase
dLocal
Flutterwave
Komoju
Mollie
NOWPayments
Opn
Paystack
ActiveCampaign
Customer.io
Segment
Canny
Amplitude
Custom Head Scripts
Pushover
Twilio SMS
Crisp
Tawk.to
Monday.com
fal.ai
Axiom
hCaptcha
Freshsales
Pipedrive
Pabbly Connect
AWS S3
MuxHover a table to isolate what it touches; click one to read its relationships. The big nodes are what everything else hangs off. organizations is referenced by 74 tables because every single record in this product belongs to an organization, and that is what makes tenant isolation a property of the database rather than something the application has to remember on every query.
all 89 tables, as text
active_boosts · admin_notifications · analytics_daily · analytics_events · analytics_funnels · announcement_dismissals · announcements · api_key_logs · api_keys · article_revisions · article_section_links · article_sections · article_snapshots · article_tag_links · article_tags · articles · assistant_actions · assistant_conversations · assistant_messages · assistant_usage · audit_logs · automation_log · automation_templates · campaign_deliveries · campaign_recipient_snapshots · campaigns · comments · credit_balances · credit_transactions · currencies · data_exports · data_imports · entitlements · faq_categories · faq_items · feature_flags · inbound_webhook_events · inbound_webhooks · languages · marketing_audience_members · marketing_audiences · membership_payment_events · membership_plans · membership_price_versions · notification_log · notification_rules · notifications · organization_limit_overrides · organizations · plans · platform_secrets · platform_settings · pluma_idempotency_keys · pluma_jobs · product_purchases · products · provider_prices · publication_authors · publication_domains · publication_merchant_connections · publication_profiles · publication_recommendations · publication_staff_memberships · publication_template_assignments · publication_template_versions · publication_templates · push_devices · reader_memberships · reader_participation_tags · reader_participations · recommendation_attributions · report_templates · roles · scheduled_tasks · segments · sending_domains · seo_meta · subscriber_preferences · subscriber_tags · subscriptions · suppressions · theme_page_sections · theme_section_library · theme_sections · translations · user_sessions · users · webhook_logs · webhooks
The chassis, and anything particular to this product. 3 required, 3 optional.
Next 16.2.10 and React 19.2.3.
The shipped application uses Supabase.
Four jobs are declared in `vercel.json`; another host needs an equivalent scheduler.
Provider modules are present for Brevo, Mailgun, Resend, SendGrid and SMTP; configure one for outbound email.
An optional service exposed by the shipped environment contract.
An optional service exposed by the shipped environment contract.
Already built — plug and play
Every provider integration in this list ships wired into the product. You bring your own keys, connect them in the admin, and go live — there is no integration code to write. Nothing is resold through us: the ongoing cost is whatever these providers charge you. Capabilities marked plan-gated elsewhere on this page unlock by plan, not by extra code.
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.