Subscription Leak Finder: A Small Tool for Finding Forgotten Subscription Waste
Subscriptions are easy to ignore when they hit your account one small payment at a time. $8 here. $12 there. A trial you forgot. A tool you used once and never opened again.
Subscription Leak Finder was built to make that invisible cost visible. Not with bank connections. Not with accounts. Just a small local-first web app that shows what your subscriptions cost per month, per year, and which ones are probably worth reviewing first.
Try Subscription Leak Finder →
What Subscription Leak Finder does
Subscription Leak Finder is a simple browser app for tracking recurring subscriptions manually.
You add the subscription name, the monthly cost, when you last used it, how often you use it, and whether you want to keep it, review it, or cancel it.
The app then gives you four useful numbers:
| Result | What it shows |
|---|---|
| Monthly total | What all your subscriptions cost each month |
| Yearly total | What they cost when annualized |
| Likely waste | What you may be paying for but not really using |
| Top 3 to review | The subscriptions most worth checking first |
The point is not to manage your entire financial life. The point is to give you one clear moment of awareness.
That fits the same thinking behind Spending Reality Check: small, private tools that make money drift easier to notice before it becomes normal.
The app uses browser localStorage to keep data in your browser instead of sending it to a backend. You can read more about how localStorage works in the MDN Web Docs guide to localStorage.
Why I built it this way
A bigger version of this app would be easy to imagine: connect your bank, detect subscriptions automatically, create user accounts, add reminders, sync across devices, build a full dashboard, maybe turn it into SaaS.
But that was exactly the trap I wanted to avoid.
Most useful beginner-friendly AI builds do not need to become platforms. They need to solve one problem clearly. The real build decision was not what features can I add. It was what can I cut and still make this useful.
That is why there is no login. No database. No bank connection. No external API. No onboarding flow. No payment system. No complicated analytics. Just the smallest useful version.
This is the kind of project that belongs on VibeCodeTools, because it shows the part of vibe coding people often skip: restraint.
What went well
The app became functional quickly. Add, edit, delete, save, clear data, calculate totals, estimate likely waste, and rank the top 3 subscriptions all worked.
That matters because a working small tool teaches more than a perfect imaginary product.
The project also stayed local-first. No backend got added. No auth. No database. No bank connection. No paid service added halfway through because it sounded impressive.
The design improved in stages too. The first version used clean cards. Then a blue and white layout. Later, a stronger teal dashboard with theme switching, a yearly spend hero section, clearer privacy messaging, and better summary areas.
The strongest technical win was keeping the active TypeScript app working while translating the uploaded JSX mockups into it. That avoided a common AI-building mistake: replacing a working app with a prettier prototype that does less.
What went badly
The build was not smooth from start to finish.
The first install and build hit setup issues, including sandbox and PowerShell problems. That slowed down the early work.
One patch attempt was too broad and briefly created a malformed migration block. It was caught and fixed, but it was a messy moment.
The files also became confusing. Some were loose .jsx files. Some were zipped. Some were duplicated. That made it harder to know which version was the real source of truth.
There were also encoding artifacts in some prototype text, so the final app needed cleaner copy instead of blindly copying the mockup text. That is a useful reminder: AI can help you move faster, but it does not remove the need to inspect the output.
What still needs work
The next step is not adding more features. The next step is testing the full flow properly.
That means checking: add subscription, edit subscription, delete subscription, refresh persistence, clear data, mobile layout, and theme switching.
The app could also use a few small automated tests for calculations and ranking. Nothing heavy. Just enough to make sure the core numbers stay correct when the UI changes.
The waste model also needs clearer explanation. Right now the app uses last-used date and frequency to help decide review priority. That is useful, but the UI should be very clear about what those fields affect. The app should not make the math feel more scientific than it is.
A simple model is fine. A simple model pretending to be smarter than it is would be a problem.
What this build teaches
Subscription Leak Finder is not impressive because it is complex. It is useful because it refused to become complex too early.
A beginner-friendly vibe coding project should not start with the biggest possible product. It should start with one repeatable problem, one useful flow, and one clear reason to exist.
For this build: the problem was subscription drift, the useful flow was manual entry, and the constraint was privacy. The cut list made the product better.
This is also why tools like the Idea Clarifier and Build Decision Matrix matter. They help you decide what the tool should do before you ask AI to build the wrong thing quickly.
FAQ
Is Subscription Leak Finder a budgeting app?
No. It does not connect to your bank, import transactions, or categorize your spending. It does one smaller job: show what your subscriptions cost and which ones may be worth reviewing first. That smaller scope is the point.
Does the app store my data online?
No. The app stores data in your browser using localStorage. There are no accounts, no backend, no database, and no bank connection. That makes it private by default, but it also means the data is tied to that browser unless export or sync is added later. For more technical context, see the MDN localStorage documentation.
Could this become a bigger product later?
Yes, but it should earn that. The next version should not jump straight into accounts, payments, or bank sync. A better next step would be better testing, clearer waste explanations, and maybe CSV import and export. Build the useful version first, then decide what deserves to be added.
Why is this a good beginner AI build?
Because it has clear boundaries. The data model is simple. The logic is understandable. The UI gives immediate feedback. The privacy constraint removes backend complexity. That makes it a strong example for someone learning to build small software with AI. For more examples, see What You Can Actually Build With AI.
Built and shipped. No accounts, no backend, no bank link.
One problem. One useful flow. One clear constraint. The smallest version that works.
Try Subscription Leak Finder →