u/rishi-raj-jain

The standard advice for global pricing is "just use ParityDeals". But it's at $19/mo per product and no free plan. For a product making few hundred dollars a month, paying a subscription whose job is to lower your prices is exactly not the best option I'd say 😅

Option	Cost model	Fits a no-MRR product?
ParityDeals	14-day trial, then $19/mo (1 product) → $99 (unlimited). No free plan.	Fixed cost to give discounts. Upside down at low volume.
Roll your own (what I did)	With Claude (so $20 one time), took an afternoon and it's $0 recurring	Yes. No fixed cost, no lock-in, no migration.

A % cut is less painful than a $19/mo fixed cost for a product making few hundred dollars a month and it's just pure cost against near-zero upside.

Rolling my own was nearly ~50 lines of code: map countries to a few discount tiers (10/25/55/75%), detect country server-side (host geolocation header, so the browser never sets its own price), one discount code per tier, an /api/parity-offer endpoint returning { percentOff, couponCode } cached ~24h, and a banner.

Yes, I gave up on dashboards, analytics, and auto-updating PPP indices. I just don't need those yet. I'm not anti-ParityDeals. I just think "use a paid PPP tool" for a small product is a high fixed cost I can't afford yet for something I can write myself with AI today.

What are others with small revenue products doing? Are you entirely skipping PPP and eating the lost conversions? or using a cheaper tool I don't know about?

Disclaimer: I am the author of the article I've linked inline.

Copy-on-write forking is a storage primitive and we all think of it as a development tool. Test a migration, spin up a PR environment, throw it away. But if forking a database is genuinely cheap, there's no law that only CI gets to do it. So what happens if a user's save is the thing that creates a fork?

I built the most extreme version I could think of: Google Docs style version history, where every save forks the whole database and writes one row into a catalog table on production, pointing at the fork. The catalog is the index and the forks are the "storage". Schema, the branch calls and the restore path are here if you want the specifics. Forking copies nothing at creation, so it's a second or two regardless of database size.

What that also ensures is referential integrity at an instant. If your document is one row, use a revisions table. The demo I created spans a title and body so I've gone ahead with the above approach.

This approach can go sideways elsewhere though. Restore repoints the whole fork, so if two tenants share a database and one rolls back, the other loses everything they wrote since. There is also no merge, and Dolt is simply better in that scenario.

Disclaimer: I am the author of the article (but I do not work at Plakar and in fact they first rejected the submission)

I got here because of the threads on this sub. There have been six or seven in the last two months and they're all some version of the same question - how do you actually back up your project, and have you ever restored one, has anyone actually tested their backups, am I the only one not sure mine still work.

Supabase does keep backups but that option is not available for free tier project, Pro is 7 days and Team only gets you to 14. That's fine for the failure of running a bad migration but it's a restore button inside the console. I can't hold it, I can't diff it, I can't restore it anywhere except back into Supabase, and if my account is the thing that has the problem then the backup has the same problem.

I know you are thinking about pg_dump and a cron job that would dump it to S3 (and it works!) but every run is a full copy even if my data changed by a couple of GB/MBs a day.

What I liked with Plakar, the open source backup tool I used is that it uses pg_dump, it shells out to the real Postgres tools, so the output is a normal dump and I'm not trusting a bespoke format with my only copy. What it adds on top is content-defined chunking, so the second snapshot only stores the chunks that changed, plus encryption by default and an integrity check. But it allows me to own my copy of the backup!!

In addition to the steps to perform the backup, I've included some cost reasoning also in the blog as to why this tool actually makes sense to own the automated backup process: https://www.plakar.io/posts/2026-07-17/portable-backups-for-managed-postgres-with-pgdump-and-plakar/#what-60-days-of-a-100-gb-database-costs-to-store.

For those of you running a restore test, what are you actually asserting after the restore? I count rows in few tables (or a count query) and eyeball it, which I know is weak, maybe/not? Would love to hear an approach if there's any to reliably see the before/after!