The kit's own payments README says this plainly, so the site will too: RevenueCat's SDKs, their coverage of store quirks and their dashboards are ahead of this package, and if you want a hosted product with a support contract you should buy theirs. The honest difference is not the feature list. It is where the purchase history lives.
Choose RevenueCat
When you want the store quirks to be somebody else's job.
Every rail has edge cases — grace periods, billing retry, refunds, family sharing, price changes, sandbox behavior that differs from production. RevenueCat has met all of them already, and their charts answer questions you have not thought to ask yet.
Choose Pithy
When the purchase belongs in the database that gates the feature.
Five tables in a D1 you own, written by a Worker you deploy. The entitlement check is a join rather than an API call, it works when the vendor is down, and no third party holds a record of what your customers bought.
On this capability alone
| Feature | RevenueCat | Pithy |
|---|---|---|
Subscriptions and entitlements | ||
| Apple, Google and Stripe on one entitlement Pithy: plus Paddle and Lemon Squeezy as merchant-of-record rails | Yes | Yes |
| Buy on iOS, be entitled on the web RevenueCat: the problem they built the business on Pithy: the same resolution, in your own tables | Yes | Yes |
| Purchase history in your own database RevenueCat: held in their data plane and mirrored to you Pithy: five tables in your D1; there is no data plane of ours | No | Yes |
| Entitlement check without a network call RevenueCat: an SDK call against their service, cached Pithy: a query against the database the request is already using | No | Yes |
| Works when the vendor is down RevenueCat: degraded to whatever your cache holds Pithy: there is no vendor in the path to be down | No | Yes |
| Mature client SDKs RevenueCat: iOS, Android, Unity, Flutter, React Native, web Pithy: HTTP and a documented route contract; no SDK is required, and none is provided | Yes | Partial |
| Charts, cohorts and revenue analytics RevenueCat: a genuine product, and a good one Pithy: the rows are yours to query; the dashboard shows purchases and entitlements, not cohort analysis | Yes | Partial |
| Store quirk coverage RevenueCat: years of accumulated edge cases Pithy: the common paths, honestly documented, with the uncommon ones yours to meet | Yes | Partial |
| No revenue share RevenueCat: a percentage above a free tier Pithy: Cloudflare bills what your Worker runs | No | Yes |
The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about RevenueCat was checked against their own documentation on 2026-08-25; both products change, and this page is a snapshot rather than a maintained contract.
Where RevenueCat wins
Six platforms, maintained, with the receipt-validation and restore flows already correct. Pithy gives you routes and asks you to call them, which is more work on every client you ship.
Billing retry, grace periods, family sharing, refunds arriving late, a price change mid-period. Every one of those is a decision somebody has to make; theirs are made.
Cohort retention, churn, realized revenue by rail. You can compute all of it from your own rows, but you would be building a second product to do it.
Apple and Google change behavior without much notice. A vendor whose whole business is absorbing that is worth the percentage to plenty of teams.
This is the one comparison where the competitor is better at the thing itself, and pretending otherwise would cost the rest of this site its credibility. The argument for the kit is not features — it is that the record of what your customers bought sits in the database your app already queries, priced by Cloudflare rather than as a share of your revenue.