Backend for solo devs · Invite-only beta
The backend plumbing, pre-built. So your side project gets to the interesting part faster.
Plurism is a shared backend I'm building for solo devs juggling more side projects than they have time for. Support, analytics, feedback, flags, waitlists, content, files, webhooks — one typed SDK, one API key.
Running on my own projects first. Inviting the waitlist once it's ready for strangers.
// How it will look on day one of your side project import { createPlurismClient } from "@plurism/sdk"; const plurism = createPlurismClient({ baseUrl: "https://api.plurism.dev", apiKey: env.PLURISM_API_KEY, }); await plurism.support.threads.create({ body: "Can't log in", category: "bug", reporter_email: "alice@acme.com", reporter_name: "Alice", }); // → { id: "thr_01k…", ref: "ACME-42", created_at: "…" }
↑ The whole integration. Everything else is a Plurism concern.
The same ten things. Again.
You've built this backend five times.
Every side project starts the same way. You're excited about the idea, and then you spend the first week wiring the same services every SaaS needs. By the time the plumbing is done, the spark is gone.
- Support inbox
- Product + revenue analytics
- Waitlist with invite flow
- Feedback + NPS capture
- Feature flags with rollout %
- Content / blog with SEO
- File uploads to object storage
- Signed outbound webhooks
- Email / Discord / HTTP notifiers
- Public changelog feed
Plurism is all ten. Written once, running on Cloudflare's edge, exposed through a typed SDK that runs anywhere JavaScript runs — Workers, Node, Bun, Deno, or an Astro / Next / Hono server endpoint.
What's inside
Ten services. One SDK.
Each has its own admin UI and SDK module. The goal is that using one doesn't force you to adopt the rest — cherry-pick the two that solve your immediate pain and wire up the others when you need them.
Support inbox
Threads with categories, custom statuses, tags, agent replies, public reporter lookup, and an inbound-email reply path. Per-tenant scoping, soft-delete, seeded from your contact form, the SDK, or an MCP tool.
Analytics
Privacy-friendly, first-party web analytics: traffic and acquisition channels, a visit → signup → activation → paid funnel with identity stitching, and revenue attribution from your own Stripe. A lightweight pixel plus a dashboard — no third-party trackers.
Feedback & NPS
1–10 ratings with optional comment. Stats endpoint per project. Auto-capture hook designed for MCP-driven apps.
Feature Flags
On/off flags with stable rollout percentage. KV hot-path cache. Missing-config path returns disabled rather than guessing.
Waitlist
Capture → invite flow with email. Status moves pending → invited → joined. Referrer tag if you want to track source.
Content
Blog, news, FAQ, and how-to entries authored in the portal or via the SDK. Served as ready-to-embed HTML with schema.org JSON-LD for SEO and answer-engine (AEO) discoverability, plus rebuild webhooks for static sites.
Changelog
Public JSON feed with a 60-second KV cache. Admin CRUD. Fires a `changelog.published` event when an entry flips from draft.
Files
R2-backed uploads, streaming in and out. 10MB cap, allow-listed content types, SVG XSS scrub on the way in.
Webhooks
Inbound relay with HMAC verification. Outbound signing in the Stripe-style `t=<unix>,v1=<hex>` format. Retry table for failed deliveries.
Notifiers
Rule-based email, Discord, and generic HTTP. SSRF-guarded outbound with IPv4 normalisation. Template substitution per event.
Transactional email — magic links, receipts, notifications — sent from your own DKIM-verified domain. Per-domain verification is live in the portal; sending opens soon.
The diff
Two hundred lines. Now four.
A support-thread ingestion endpoint you've written before — auth, validation, D1 writes, email fan-out, the error envelope you'll regret.
import { Hono } from "hono"; import { z } from "zod"; import { drizzle } from "drizzle-orm/d1"; import { Resend } from "resend"; // + api-key auth middleware // + rate-limit middleware // + D1 schema migrations // + cross-tenant isolation // + soft-delete cascade // + IP hashing for privacy // + request_logs table // + error envelope // + Sentry capture // + outbound webhook signing // + tests for all of the above app.post("/support/threads", auth, tenant, rateLimit, async (c) => { /* … 180 more lines … */ });
import { createPlurismClient } from "@plurism/sdk"; const plurism = createPlurismClient({ baseUrl: "https://api.plurism.dev", apiKey: env.PLURISM_API_KEY, }); await plurism.support.threads.create({ body, category, reporter_email, reporter_name }); // Included for free: // ✓ scoped API key auth // ✓ per-tenant rate limit // ✓ cross-tenant isolation // ✓ IP-subnet-hashed request log // ✓ retry on transient 5xx (GET) // ✓ X-Plurism-Request-Id correlation // ✓ notifier fan-out (email/Discord/HTTP) // ✓ admin SPA to manage it all
Pricing
Free while it's in beta.
Plurism is invite-only right now and not taking cards. Everyone in the beta uses it for free. Paid plans will arrive once there's enough real usage to price them honestly — no made-up tiers in the meantime. The waitlist gets first access and a say in how it's priced.
When plans do land, billing is usage-based (reads are free), and there'll be a genuinely usable free tier — enough for a side project's support inbox, a landing-page waitlist, or a feature-flag experiment.
Early access
Leave an email. I'll invite you when it's ready.
Plurism is running — I use it for my own projects — but it isn't open to strangers yet. I want to stress-test it on real traffic with people I can actually respond to before flipping the signup switch. Leave your email and I'll invite you when the next slot opens.
Uses Plurism's own waitlist service. No marketing emails — just the invite when it's your turn.
Questions
Things people ask me.
How ready is this, really?
I've built it, deployed it, and run it for my own projects. I haven't put it through a stress test with real user traffic yet — that's what the waitlist is for. When the first handful of invited users are in and the sharp edges are sanded down, the gates open to strangers. Until then: building in public, not selling.
Is this a database or a backend-as-a-service?
Not quite either. General-purpose backends give you a database and auth, and you build every feature on top. Plurism is the opposite shape: it's the opinionated feature layer — support inbox, analytics, feedback, flags, waitlists, content, files, webhooks, notifiers — the stuff every indie SaaS rebuilds from scratch. Use Plurism for the repeat plumbing and your favourite database for your own domain logic. They sit side by side.
Do I need to be on Cloudflare to use it?
No. Plurism runs on Cloudflare; your app can live anywhere. If you're on CF Workers the SDK will use a service binding (zero egress). Otherwise it's HTTPS from Node, Bun, Deno, Astro, Next, Hono, or a plain fetch.
What does the free tier actually look like?
Planned — a genuinely usable free tier: 1 project with access to every service. Enough for a landing-page waitlist, a side project's support inbox, or a feature-flag experiment. I'll set the exact limits before launch, once I've watched what real usage actually costs to run.
What about GDPR, data residency, deletion?
Data will live in Cloudflare D1 and R2. Soft-delete is first-class across every model — rows are marked and excluded from reads immediately. Hard-delete and full data-export endpoints are on the roadmap; if you need either before I ship them, the waitlist form asks about use cases and I'll prioritise.
Can I use it from Python or Go?
Not with a first-class SDK yet — TypeScript is the only typed client. Every endpoint has a stable REST surface with JSON envelopes, so any HTTP client works. Python and Go SDKs ship when there's enough signal from real users that it's worth maintaining them properly.
Who's building this?
A solo dev from Melbourne. I run it while running my own SaaS projects, which means: I use it before you do, I reply to bug reports personally, and I won't pivot it to enterprise. What I can't promise is a big team's response time — if you file a non-critical bug on a Saturday, it's Monday.
What happens if this project gets abandoned?
Your data sits in Cloudflare D1 + R2 — structured, exportable. If Plurism winds down I commit to 90 days written notice, the final billing cycle refunded, and an export script targeting your own CF account. It's in the terms of service.
Before you go
Leave an email so you hear when it's ready.
The waitlist is the only way in right now. Paid tiers light up after the first group of invited users has run real workloads through it without anything falling over.