A service that reminds you before a subscription renews. Most products send a receipt after the charge, by which point cancelling is too late. LapseWatch moves the reminder ahead of the charge and lets people choose the channel it arrives on.
The problem
Subscription cost is diffuse by design: each charge is small, the dates are scattered across the month, and the notice is buried in an inbox. By the time someone notices they are paying for something they stopped using, several periods have usually gone by.
The obstacle is not that people are unwilling to manage subscriptions. It is that the reminder arrives at the wrong moment.
Technical points
Notifications where people already look. Reminders go out over LINE, email or desktop notification, and sync to Google Calendar so renewal dates appear alongside everything else someone already checks — rather than inside one more app they have to remember to open. Data exports to CSV or JSON: a subscription list belongs to the person who built it and should not be locked in.
A Chrome extension built to read as little as possible. The extension detects subscription details on a page, but it reads only a narrow window of text around a matched keyword rather than the page as a whole. That is a deliberate trade: detection accuracy suffers, and in exchange there is a clear and narrow bound on what the extension can see. An extension that asks to read every page you visit is hard to justify installing, however legitimate its purpose.
Subscription billing and statutory e-invoicing. Integrating a payment gateway’s recurring-charge flow, and issuing a statutory electronic invoice after a transaction (ECPay, Taiwan’s e-invoice system).
What this domain taught me is where the boundary of responsibility actually sits. The gateway supplies the mechanisms — scheduled charges, APIs to issue and void invoices, reconciliation files — but nearly all of the judgement stays on the merchant’s side:
- Whether a failed charge should retry, notify, or suspend the service is a product decision, not a gateway feature.
- Whether a refund is handled by voiding the invoice or by issuing a credit note depends on timing. Under Taiwan’s rules, after the 13th of each odd month you can no longer void invoices issued in the previous two months, because they have already been filed with the tax authority — past that window a credit note is the only option, and the system has to know which case it is in.
- The gateway calls back to report the result, and re-sends on failure up to four times. The crediting logic therefore has to be idempotent — processing the same callback once and four times must land in the same place — or one network hiccup double-bills someone.
- Reconciliation files have to be matched against your own records, and what happens when they disagree is yours to define.
What I have built so far is the main path — recurring charges and invoice issuance. Several of those edge cases are not finished. But they are the part of this problem I actually learned something from.
E-invoicing is not a Taiwan-only concern: the EU, Latin America and India all operate mandatory e-invoicing regimes, which makes this a compliance-engineering domain that reads clearly outside Taiwan.
Privacy by design. No bank-account linking and no cross-site tracking. The subscription list is maintained by the user, or filled in by the extension inside the narrow boundary described above.