一個在自動續訂之前提醒你的服務。多數訂閱制產品的通知設計是扣款後寄一封收據，那時候要取消已經來不及。LapseWatch 把提醒挪到扣款之前，並讓使用者選擇用什麼管道收到它。
解決什麼問題
訂閱的成本是分散的：單筆金額不大、扣款日期各不相同、通知埋在信箱裡。等到發現「這個我根本沒在用」的時候，通常已經多付了好幾期。
問題不在於使用者不想管理訂閱，而在於提醒出現的時機是錯的。
技術重點
多管道通知
提醒可以透過 LINE、Email 或桌面通知送出，並能同步到 Google Calendar，讓到期日出現在使用者本來就會看的地方，而不是又一個要記得打開的 App。資料也可以匯出成 CSV 或 JSON：訂閱清單是使用者的資料，不該被鎖在服務裡。
Chrome 擴充功能，刻意最小化蒐集
擴充功能會自動偵測網頁上的訂閱資訊，但它只讀取比對到關鍵字前後的一小段文字，而不是整頁內容。
這是個明確的取捨。偵測準確率會下降，換到的是「這個擴充功能能看到什麼」有一個清楚且狹窄的上界。一個要求讀取所有網頁內容的擴充功能，無論用途多正當，都很難說服使用者安裝。
訂閱計費與法定電子發票串接
串接金流閘道的定期定額扣款，並在交易後開立法定電子發票（ECPay，台灣的電子發票系統）。
這個領域讓我學到的一件事是責任分工的界線在哪裡。金流服務商提供的是機制——排程扣款、開立與作廢發票的 API、每日對帳檔——但幾乎所有的判斷都留在商家系統這一側：
- 扣款失敗時要重試、通知、還是暫停服務，是產品決策
- 退款要用「作廢」還是「折讓」取決於時效——前者是把發票整張取消，後者是保留原發票、另開一張沖銷部分金額。以台灣的規定為例，每年奇數月 13 日之後就無法作廢前兩個月開立的發票，超過這個窗口只能改開折讓單，而這個判斷必須由系統自己做
- 金流服務商在交易後回呼（callback）通知結果，而這個通知最多會重送 4 次。入帳邏輯因此必須是冪等的——同一筆通知處理一次和處理四次，結果必須完全相同——否則一次網路異常就可能重複計費
- 金流商每日提供的對帳檔要跟自己的交易紀錄逐筆比對，對不上的時候該補款、該退款還是該人工介入，也是自己的事
我目前實作到的是扣款與發票開立的主要流程，上面那些邊界情況有一部分還沒做完，但它們是我在這個題目上真正學到的東西。
電子發票不是台灣獨有的題目。歐盟、拉丁美洲與印度都有強制的電子發票制度，這是個國際上看得懂的合規工程領域。
隱私設計
不串接銀行帳戶、不做跨站追蹤。訂閱清單由使用者自己維護，或由擴充功能在受限範圍內協助填入。