I built Perks Reminder, a free open-source app for tracking credit card benefits, recurring credits, welcome bonus deadlines, annual fee ROI, and loyalty expirations.
The product problem is simple: recurring benefits are calendar problems.
A monthly dining credit, an annual hotel credit, a signup bonus deadline, and a points expiration date all need different reminder behavior. They are not hard to track individually, but they become annoying once you have enough of them.
Live app:
https://www.perks-reminder.com
GitHub:
https://github.com/lifan-builds/perks-reminder
Design Constraints
I wanted the app to be useful without becoming a full personal-finance system.
That led to a few constraints:
- no bank account scraping
- user-controlled card and benefit data
- clear recurring due dates
- email reminders before expiration
- import / export
- mobile-first UI
- self-hostable source
The goal is not to infer every transaction. The goal is to make the benefits visible enough that users stop missing expiring credits.
What It Tracks
Perks Reminder tracks:
- recurring card benefits
- welcome bonus deadlines
- annual fee ROI
- complete / partial-complete status
- notes
- custom reminders
- loyalty points and miles expiration
- import / export
The loyalty tracker is split into a separate subsite:
https://loyalty.perks-reminder.com/
Card benefits and loyalty expiration dates behave differently, so I kept the workflows separate while sharing the login system.
The 2.1 Update
The latest update focused on mobile UX and practical benefit usage notes.
Most users check benefit status from a phone, not from a desktop. So the mobile UI now makes expiring benefits more prominent, makes completion actions faster, and supports views by card, category, and due date.
The more interesting feature is Benefit usage manuals.
For a lot of card credits, the useful information is not only "this card has this benefit." Users also want to know:
- how the credit usually triggers
- which merchants count
- whether gift cards work
- when credits tend to post
- what common traps exist
- whether recent data points changed the answer
That turns the app from a checklist into a practical operating manual.
Tech Stack
The current stack:
- Next.js
- React
- Tailwind CSS
- Prisma
- PostgreSQL
- NextAuth
- Resend for email reminders
- Vercel cron jobs
The source is open, and self-hosting is supported for people who want complete control over their data.
The Hard Part Is Data Freshness
The hard engineering/product problem is not only reminders. It is maintaining real-world benefit data.
Card benefits change. Redemption paths change. Merchant coding changes. Community data points become stale.
That is why the launch asks users to report missing cards, outdated rules, and wrong usage notes.
I launched the update first on USCardForum/Nitan because the users there know the edge cases:
https://www.uscardforum.com/t/topic/388701
Feedback Wanted
I would appreciate feedback on:
- missing card data
- recurring-benefit modeling
- reminder timing
- self-hosting setup
- import/export workflow
- whether usage manuals are a useful format
Live app:
https://www.perks-reminder.com
Top comments (2)
Keeping this out of full personal-finance territory feels like the right product constraint: no bank scraping, user-controlled benefit data, and reminders focused on expiring credits make the job clear. The separate loyalty tracker also makes sense because a monthly dining credit and points expiration date behave differently in practice, and the 2.1 mobile focus matches when people actually check this stuff. The founder/engineering challenge I'd watch is provenance and staleness on the usage manuals; merchant coding, gift card behavior, and posting delays all need an age, confidence level, and update path.
My immediate thought with any project touching credit card benefits, even indirectly, always goes to the data challenge. Keeping that information current and accurate is a beast. We've wrestled with similar problems in past projects where external data sources were critical but notoriously unstable. Relying on scraping is a constant cat-and-mouse game, and direct API access for this kind of specific, often proprietary, benefit data is usually either non-existent or comes with a prohibitive price tag for a FOSS project.
This often pushes projects like yours towards community-driven data or a more manual curation model, which brings its own set of challenges around moderation, consistency, and maintaining quality at scale. Did you consider a system where users could propose updates or new benefits, perhaps with some form of peer review? Or are you leaning on a more centralized approach for the core benefit data, and how do you plan to scale that maintenance effort as the number of tracked cards and benefits grows?
Beyond just sourcing, the accuracy of that data is paramount for user trust. If someone misses out on a credit due to outdated information, it erodes confidence quickly. For a FOSS project, maintaining that level of data integrity over time, especially as card programs evolve, often becomes the single largest operational burden. It's a continuous integration problem not just for code, but for the actual content that makes the app valuable.