Pluralize
Toggle menu

Introduction

The weekend problem

You had an idea on Saturday. By Sunday night you have a working prototype: a recipe manager, a habit tracker, a tiny analytics dashboard. It works for you. It's great.

Then someone sees it and says "I want to use this." And suddenly the next step isn't a feature — it's a wall of plumbing:

  • Authentication. Signup, login, password reset, email verification, token refresh.
  • Per-user data. A way to store user A's records so user B never sees them.
  • File uploads. With storage that isn't your laptop and doesn't become an XSS vector.
  • Billing. A way to take money — with plans that actually gate features.
  • Plan limits. So the free tier doesn't eat your wallet.
  • Transactional emails. Welcome, reset, receipt — and ideally in the user's language.

Each of those is a week. Most weekend projects die on this wall.

What Pluralize is

Pluralize is a backend that ships all six out of the box, behind a single SDK call.

import { Pluralize } from '@pluralize/sdk';
 
const app = Pluralize.init({ appId: 'app_xxx', apiKey: 'pk_live_xxx' });
 
await app.auth.signup(email, password);
await app.db.collection('recipes').insert({ title: 'Ramen' });

Three lines, zero infrastructure. Every user is isolated at the database row level. Plan limits are enforced at the API edge. Stripe checkout is two more SDK calls. You own the frontend and every product decision; Pluralize owns the boring middle.

The tagline is literal: build for one, pluralize for thousands. You write the app the way you'd build it for yourself, and the SDK turns it into a multi-tenant product as soon as real users show up.

Who this is for

If you build with AI assistance

You can prompt a model to write a polished React component in ten seconds. What you cannot prompt it to produce reliably is multi-tenant Postgres row isolation, refresh- token rotation, Stripe webhook signature verification, and per-tenant rate limits — all wired together, all correct on the first try.

Pluralize is exactly the layer that AI tools can't generate for you. You keep prompting for features; we handle the plumbing underneath. The result is a real product, not another demo that only runs in your browser with a hardcoded user.

If you're a junior developer

The six things in the list above are each an interview-grade topic. Building all six correctly is a senior-level project that usually takes months. Pluralize lets you ship something real while you're still learning — and lets you learn the underlying concepts by watching a working system, not a textbook.

You'll still write React, TypeScript, CSS. You just won't write auth middleware or argue with Stripe webhooks at 2 AM.

If you're a senior developer

You've built this stack twice. You know exactly how long "just auth" takes the moment you add email verification, password reset that doesn't leak timing information, and session invalidation across tabs. Pluralize is the skip button for the 80% you've already internalized — so the working day goes to the 20% that actually differentiates your product.

What you gain, concretely

  • Time. A typical "MVP with auth + data + billing" saves 2-4 weeks of work for one developer. The first useful version of your app ships in a weekend, not a quarter.
  • Correctness by default. The plumbing is shared across every Pluralize app; bugs get fixed once for everyone. Your own hand-rolled auth gets debugged by you, on a Thursday at midnight.
  • Multi-tenancy for free. Every authenticated user is a tenant. Their data is isolated at the row level in Postgres — not by a WHERE user_id = ? you have to remember in every query.
  • Monetization on day one. Flip a switch in the dashboard, wire one SDK call, and you can charge. Plans, features, and limits are declarative: define them in the dashboard and the SDK enforces them.
  • One less stack to host. No Postgres, no Redis, no worker queue, no S3 bucket. You ship a frontend (and, optionally, your own API routes); we handle the rest.

What Pluralize is not

Being clear about the scope helps you decide if it fits your project.

  • Not a replacement for your own backend. If you need custom business logic, long-running jobs, or third-party API integrations, write your own server and call Pluralize from it. The SDK works on the server too.
  • Not a realtime sync engine. No live subscriptions or CRDT merging yet. For that, reach for something like Supabase Realtime or Liveblocks.
  • Not a no-code tool. You still write code. Pluralize removes the boring parts of the stack; it doesn't remove the building.

Mental model in one picture

  ┌──────────────────────────────────────────────────────┐
  │  Your frontend (React, Next.js, Astro, anything)     │
  │                                                      │
  │  import { Pluralize } from '@pluralize/sdk';         │
  │  const app = Pluralize.init({ ... });                │
  └─────────────────┬────────────────────────────────────┘
                    │ one HTTPS call per method
                    ▼
  ┌──────────────────────────────────────────────────────┐
  │  Pluralize API (this is us)                          │
  │  • Auth + tokens          • Files (Vercel Blob)      │
  │  • Per-tenant Postgres    • Stripe billing           │
  │  • Entitlements + limits  • Transactional email      │
  └──────────────────────────────────────────────────────┘

The SDK talks to our API. Our API talks to Postgres, Stripe, Blob, Resend. You never deploy any of that — you just import the SDK.

Ready to build?

  • Quickstart — get an app signing users up in about ten minutes.
  • Authentication — login forms, session hooks, protected routes.
  • Data — collections, filters, unique fields, share links.
  • Files — uploads with MIME and size guardrails.
  • Billing — Stripe checkout and plan entitlements.
  • Server-side — verify tokens in your own backend; cookie + proxy patterns; ready-made auth route handlers.
  • Pricing — what Pluralize charges you (Hobby is free), platform caps, and what happens when you hit one.