A renewal reminder sounds like a tiny feature. Pick a date, send a notification, done.
In practice, it touches dates, permissions, edits, cancellations, free trials, device limits, time zones, operating-system behaviour, and a surprisingly important product promise: the reminder should stay private.
Glint schedules reminders on the device instead of sending them through a notification server. That choice keeps renewal names, prices, and dates out of a remote notification system—but it also changes how the feature has to be built.
A reminder is derived state
The subscription record is the source of truth. The notification is a scheduled consequence of that record.
When a renewal date changes, the old notification is no longer merely inaccurate; it is now actively misleading. When a subscription is cancelled or archived, its pending reminders must disappear. When notifications are re-enabled, the schedule has to be rebuilt from current data rather than revived from stale identifiers.
This is why reminder work is mostly lifecycle work:
- Create a subscription and schedule its valid reminders.
- Edit the amount, date, cycle, or reminder offsets and replace the old schedule.
- Cancel or delete the subscription and cancel pending notifications.
- Restore a backup and rebuild notifications for the new device.
- Change the global reminder preference and reconcile subscriptions that use it.
The visible banner is the final five percent. The other ninety-five percent is keeping it truthful.
Local delivery is private, not infallible
Glint lets people choose a lead time before a renewal. Pro can attach multiple lead times to one service, and trial tracking adds a last-chance reminder around the trial end.
Those notifications are scheduled locally. Glint does not upload notification content to a server and does not generate a push token.
That is a meaningful privacy advantage, but it is not a guarantee that every notification will appear. Delivery still depends on notification permission, device settings, operating-system scheduling, and battery policies. A responsible product has to say that plainly. Glint is a planning aid; cancelling with the service provider remains the user’s responsibility.
Trust is damaged when privacy language quietly becomes reliability marketing. The honest statement is stronger: the reminders are local, the app does not run a push server, and operating systems still have the final say over delivery.
Free trials deserve different treatment
A normal renewal repeats. A free trial has a conversion moment: nothing has been charged yet, but a future price is approaching.
Counting that future price as current spending would overstate the user’s totals. Ignoring the date would make the tracker much less useful. Glint treats the trial as a reminder problem first and a spending problem only after it becomes paid.
That distinction sounds small, but it is a good example of product modelling. Two records can look similar in a form while representing different user intent. The correct interface follows the intent, not just the shared fields.
The lesson beyond notifications
Any feature that mirrors underlying data—a reminder, calendar event, search index, cached total, backup, or badge—is a second system that can drift away from the first.
The implementation question is not only “how do we create it?” It is also:
- What invalidates it?
- What removes it?
- How is it rebuilt?
- What happens when permission disappears?
- Which source wins after a restore or conflict?
Small apps feel dependable when these invisible answers are boring and consistent. That is the kind of boring worth building.