Subdue, then Subscriptions

The problem

Subscriptions are designed to be forgotten.

Streaming, music, AI tools, domains, hosting. Each one is small, each renews silently, and together they form a monthly leak nobody has a number for. The failure moment is always the same: a charge lands for something you meant to cancel, or a domain lapses because the renewal mail drowned in the inbox.

The category's answer is to ask for your bank login. That is the most sensitive data a person has, requested to solve what is fundamentally a list and a reminder. I refused that trade in both acts, which is the one decision that never changed.

My original read was that this was a wide problem, and the model was Rocket Money: track everything, then make cancelling easy. That was the assumption the first act was built on, and testing it honestly is what produced everything that follows.

The bar either version had to clear: adding something takes seconds, the reminder lands where life already happens, and one glance answers what you are actually spending.

Subdue home with the next renewal and a billing calendar

One glance, then get on with it. What is coming up, and a month calendar with a coloured dot on every billing date. Tap a date to see exactly what lands that day.

Subdue subscriptions grouped by category with per category totals

Categories built for the modern stack. Not generic budget buckets: Movies, AI and Productivity, Music, Domains and Hosting. Foreign currency items show the converted rupee amount underneath.

Subdue spending screen with monthly total, yearly projection and a category donut

The number nobody has. True monthly spend with yearly plans divided by twelve, a yearly projection, and the category donut that shows where it actually goes. Derived live, never stored.

Subdue settings with Google cloud sync, theme and currency preferences

Connecting Google is the product, not a settings chore.

One tap connects the account and the calendar together, and the copy promises what the code does: local subscriptions survive the connection. Every subscription then becomes a recurring event in a dedicated SubDue calendar, never in your personal one, carrying the amount in the title and the reminders you chose.

Guest mode means none of this is a wall. The full product works with no account at all, storing everything on your device. Sign in is a choice, not a gate.

Its own calendar, one tap to hideRecurrence handed to GoogleReminders you picked, translated

The mechanism

Reconciliation, not reminders.

Every sync rebuilds the calendar to match the database: one event per subscription, and any event whose subscription is gone gets deleted. Drift becomes structurally impossible, and a deleted calendar simply gets recreated.

The politeness

Its own calendar, never yours.

Subdue writes only into a calendar it created. One tap hides everything it does, and deleting that calendar removes every trace of the app. Respect encoded in architecture, not promised in a policy.

The durability

Google does the recurring.

Each event carries an RRULE, so Google rolls the reminder forward forever. The reminder outlives the session, and keeps working even if you never open Subdue again. Which, as it turns out, matters.

Still live, still free

Try act one yourself. It takes about thirty seconds.

No signup needed to look around, no bank access ever asked for. Add one subscription, connect Google, and watch the reminder appear in your own calendar.

Open subdue.in →

Works on phone and desktop

The hinge

The market answered. I listened.

I put it in front of a focus group. The feedback was warm: the interface, the calendar idea, the fact that it did not want their bank. Then I watched the usage, because usage is the only feedback that cannot be polite. A small number of signups, no sustained habit. The product worked; the container was wrong.

That evidence sharpened the read instead of ending it. Subscription creep is real, but for most people it is not painful enough to earn a new daily habit. Nobody wants another app to open. What they valued was the reminder itself, arriving where they already live, a few days before the charge.

So the pivot was a re-architecture, not a retreat. If the job is delivery, the sharpest tracker is the one with no app to open at all. Act two is that answer, built on everything act one proved.

Three options were on the table, and picking the third is the entire case study:

Option 1Push harder: add features, market it, chase the adoption curve

Option 2Let it quietly rot and never mention it again

ChosenBelieve the evidence. Keep Subdue live for the people it fits, and build the second answer: the same job, delivered invisibly.

Subdue stays live, unchanged. Further investment waits for demand that has not appeared. That restraint is the decision, not the absence of one.

What carried over

Google Calendar as the delivery surface
A dedicated calendar, never the primary one
Reconciliation discipline, rebuild to match truth
Derive spending, never store it
No bank access, no exceptions

What got deleted

The multi user database
Row level security
The OAuth token vault
Guest mode
Premium gating
The app shaped container itself

Part two · The invisible answer

Subscriptions. No app to open, and it never misses.

The same job, solved invisibly. A Google Apps Script system inside my own account: a spreadsheet is the database, a daily automation is the engine, and the calendar and inbox I already open are the interface. Zero servers, zero cost, shipped in one day, and it runs my renewals today.

Privatesingle user by design

Jul 2026shipped in one day

24 itemsrunning autonomously

₹0to build and to run

Because the script runs as the owner, it has native access to Sheets, Calendar and Gmail: zero API keys, zero OAuth, zero servers. For a single user tool, authentication, the hardest problem, simply dissolves.

subscriptions · home

The Subscriptions app home screen with a mini calendar and upcoming renewals

Three screens, one of them a calendar.

Today in gold, dots on due dates, and the next 90 days grouped by month underneath. Free items are tagged as free, because several are telco bundle perks that would otherwise inflate the totals. Tap any date to see exactly what is due, or add something on it.

Personal domains redacted

google sheets · the database

The Google Sheet backing the Subscriptions app, one row per renewable item

The database is a spreadsheet, and it stays human.

One row per renewable thing across fifteen columns, including the calendar event IDs that make sync idempotent. The app is the front door, but the sheet stays a normal editable spreadsheet, and a rebuild button reconciles everything from it. The sheet wins, always.

Aryan's own data

The heart of the product

Every morning at 8am, the system checks itself.

Branch one

Three days out

The item joins that morning's digest email. Mail goes out only on days something actually happened, so there is no daily noise to learn to ignore.

Branch two

Date passed, auto renew on

The charge is logged, the date advances one billing cycle, and fresh calendar events appear. The spending history builds itself as a side effect.

Branch three

Date passed, auto renew off

The item is marked expired, its calendar events are removed, and it turns red in the app. Nothing goes silently stale again.

One subtle fix earned its place here: naive month arithmetic turns January 31 plus one month into March 3. The advance function clamps to the last day of shorter months, which is exactly what real billing systems do.

Both acts · The calls

Five decisions across both acts, each with the road not taken.

This is the part of product management that does not screenshot well: what got chosen, what got rejected, and the tradeoff each call accepted.

The calendar is the notification system.

Rejected: ~~building push infrastructure inside the app~~

Both acts deliver through Google Calendar rather than their own notifications. It avoids permission prompts and yet another app begging for attention, and it means the reminder keeps working long after the product is forgotten. Which is precisely what happened, and precisely why it still worked.

No bank linking, in either version.

Rejected: ~~transaction scanning, the category default~~

Rocket Money style auto detection needs the most sensitive data a person owns to solve a list and reminder problem. Manual entry takes seconds. The trust cost of the alternative was wildly out of proportion to the job.

Apps Script for act two, not a real app.

Rejected: ~~a static web app calling Google APIs, and no code tools~~

Three architectures were evaluated. A standalone app meant rebuilding OAuth, token refresh and key management for a single user, infrastructure with no added capability. No code tools were faster but gave up control of the rollover logic and calendar design, which are the entire product. Accepted tradeoff: a Google banner on the page and triggers that fire within an hour rather than a minute.

One row per renewable thing.

Rejected: ~~one row per website with two date columns~~

The old sheet stored a site with a domain date and a hosting date side by side, a shape that cannot carry per item reminders, amounts or statuses. Normalising splits one website into two rows, and the interface regroups them per site so the user keeps the simple mental model while the data stays clean.

Cancel and delete are different verbs.

Rejected: ~~one destructive action for both~~

Cancel keeps the row for history, clears the calendar, stops auto renew and drops it from totals. Delete erases everything, and its dialog actively pushes people back toward cancel. In a system built on history, the destructive path should be the harder one.

Both acts · Deliberately not built

The best decisions were the cuts.

Every one of these was designed far enough to know it would work, then killed on purpose.

Gmail auto detection

A full design existed: parse receipts, queue suggestions for approval, optionally use an LLM to extract them. Killed because the system's entire value is being simple enough to trust, and an email parser is a component you babysit forever.

Preserving calendar history on cancel

Ending recurring series at the cancellation date instead of deleting them was designed and dropped. The calendar's job is that future dates are correct; the renewal log already holds the permanent money history.

The Next up hero card

Built, shipped, then removed once the mini calendar landed and the same item could appear three times on one screen. It was my own earlier design, which is exactly why it needed cutting.

Payment verification

No sheet based tool can confirm a charge actually succeeded, so the system does not pretend to. Stating a limitation beats faking a capability.

The paid tier in act one

Premium was designed and gated in the interface, and never switched on. Adoption did not justify charging, and building a checkout for users who were not there would have been the real waste.

Parked with reasons: promo price switching until the pattern recurs, merged same day reminders, multi currency in act two, and any further investment in Subdue itself. Each waits for evidence, not enthusiasm.

Both acts · How it was built

AI wrote the code. The judgment was mine.

Act one

Production grade, honestly.

React and TypeScript on Supabase, with OAuth state signed against CSRF, tokens refreshed on a buffer, and one bad record skipping instead of failing a whole sync. The engineering was never the problem.

Act two

Twenty iterations in one day.

Nine backend and eleven frontend passes on a roughly 500 line script, dogfooded on a real phone with real data the same day. That loop caught things design review never would, down to why iOS form inputs must be 16 pixels.

The method

Ship, watch, then decide.

The first act tested a market assumption and returned a clear answer. Reading that answer honestly, and spending one day instead of one quarter on the response, is the part I would repeat.

A full product for everyone.

No app to open at all.