Compare
ShipRev and building it yourself
One way to start is to wire a few services together. This page lists what that wiring has to do once you sell more than one plan, row by row, next to where ShipRev holds the same thing.
ShipRev
One service that keeps identity, subscriptions, usage and entitlements on the same customer record, with a Server SDK your backend calls.
Building it yourself
An identity service, a payment provider, feature flags and usage tables, connected by your own code, which also keeps them in step.
The main difference
When you build it yourself, keeping sign-in, subscriptions, usage and limits in step is your code's job. In ShipRev they live on one customer record and change together in one transaction.
Row by row
What each piece involves
| What you need | In ShipRev | Building it yourself |
|---|---|---|
| Where plan limits live | In versioned plans: each plan grants capabilities, either a feature that is on or off or a quantity with a limit. Your code names capabilities, not plans. | In your code or your database, next to the plan you read from the payment provider. You keep the two in step.[1] |
| Changing a plan's price or limits | Publish a new version of the plan without changing code. Existing subscribers keep the version they bought; moving them to the new version in bulk is not available. | Change the price with the payment provider and the limits in your code, deploy, and decide yourself what existing subscribers get.[2] |
| Plans in Stripe | Each published version is synced to Stripe, with a status of syncing, synced or failed. | You create the products and prices in Stripe and keep them matched to your plans.[2] |
| Deciding on a request | The Server SDK returns a ruling with the remaining balance, marked as live or degraded. | A flag lookup or a database query you write. Working out what is left, and what to do when the lookup fails, is your code.[3] |
| Recording usage | The Server SDK reports usage events. A refused event is set aside without holding up the others. | A usage table, the code that writes to it, retries, and a way to find events that failed.[4] |
| Work whose cost is known afterwards | Reserve an amount before the work, confirm what was used, and unconfirmed reservations are reclaimed. | Holds, releases and a clean-up job for holds that are never settled, which you write.[5] |
| Resetting allowances | Allowances reset when their period ends, in the service. | A scheduled job that you write and run, matched to each subscription's period.[6] |
| Going over an allowance | Each capability carries one of three overage policies: allow and bill, block, or prompt an upgrade. | Code you write that decides what happens past the limit, applied wherever the limit is checked.[7] |
| Your customers' teams | Sign-up creates the account and its buyer organization; members join by invitation and can belong to more than one organization. | Organizations and invitations from your identity service, mapped to subscriptions by your code.[8] |
| Self-service for your end users | End users choose a plan, check out and change plan, in the end-user portal or in your own pages. They cancel in your own pages, with the React subscription panel or the public API, and resume or change their card in Stripe's billing portal, which you open for them through the public API. | Pages you build, or a payment provider's portal that knows the price but not your limits.[9] |
When to build it yourself
When building it yourself is the better choice
You need it running today
ShipRev is not open yet: the managed cloud is built but not yet open, and the source repository is not public.
You sell one plan with no usage limits
With a single plan and nothing to count, there is little to keep in step, and a payment provider on its own may be all you need.
You need something ShipRev does not have
ShipRev does not offer enterprise SSO, Server SDKs for languages other than Node.js, or event notifications to your systems today. If you need these, you will build them either way.
Sources
Where each row is described
- [1] ShipRev docs: Products, capabilities and plans · read 2026-11-05
- [2] ShipRev docs: Plan versions · read 2026-11-05
- [3] ShipRev docs: Rulings · read 2026-11-05
- [4] ShipRev docs: Report usage · read 2026-11-05
- [5] ShipRev docs: Reserve, confirm and release · read 2026-11-05
- [6] ShipRev docs: Allowances and how usage is cleared · read 2026-11-05
- [7] ShipRev docs: Overage policies · read 2026-11-05
- [8] ShipRev docs: Buyer organizations · read 2026-11-05
- [9] ShipRev docs: Checkout and self-service · read 2026-11-05