Recurr
A local-first subscription tracker for India that I designed and built end to end with AI.
- Role
- Product Design + Build
- Timeline
- 2025 · ~1 month · Self-initiated
- Platform
- Android (iOS next)
- Type
- 0 → 1 · live on the Play Store
- Team
- Solo, end to end
At a glance
Problem
People in India lose track of what they pay for. Renewals hit silently, free trials convert without warning, and everything is scattered across apps and bank SMS.
Approach
A calm, private, on-device tracker that reads the renewals already sitting in your SMS, shows what's coming, and reminds you before money leaves your account.
Outcome
Shipped a complete v1.0 on Android, with iOS next. Designed, prototyped and built single-handedly, from the first Figma frame to a working app, using Claude.
0→1
Designed & shipped solo
5
Core screens, one focused job each
100%
On-device. No account, no servers
₹
Built for Indian SMS & INR
The problem
The problem
Subscriptions creep. A trial here, an OTT plan there, an AI tool you forgot you were paying for. The cost is small each time and invisible in aggregate, until the year-end total surprises you.
In India the friction is sharper. Most renewals arrive as bank and UPI SMS, not tidy email receipts. Existing trackers assume you'll type everything in by hand, which nobody sustains, and they're built around dollars and Western services.
- ✺Renewals and autopay mandates hit silently
- ✺Free trials convert before you remember to cancel
- ✺Spend is scattered across apps, cards and SMS
- ✺Manual entry is the first thing people abandon
Process
How I approached it
- 01
Framed the real job
The job to be done isn't 'list my subscriptions', it's 'never be surprised by a charge'. That reframing pushed reminders, the calendar and a clear projected total to the centre, and pushed data entry to the edges.
- 02
Removed the entry tax
If manual logging is what people quit, the product has to fill itself. The renewals are already in the user's SMS, so the app reads them, recognises the service, guesses the amount and cycle, and asks the user only to confirm.
- 03
Designed for calm, not dashboards
Money apps lean anxious. I chose a quiet dark surface, one confident accent and large, legible numbers so the most important thing on every screen is the figure you came to check.
- 04
Designed and built in one loop
I prototyped directly in code with Claude, so design decisions were tested against a real, running app on a real device, not just static frames. Building tightened the design.
The work
Screen by screen
Home — the one number that matters
The first thing you see is projected spend for the year, then what's renewing in the next seven days and any active trial. Glanceable in two seconds, which is all the attention a tracker should ask for.
Subscriptions — where the money goes
Trials are surfaced first because they're the riskiest. 'Where your money goes' breaks spend down as a share of your monthly total, not against an imaginary budget, so the bar means something honest.
Calendar — what's coming up
Renewals grouped by horizon: due today, next 7 days, next 30. The same data as the list, reframed around time, because the question is usually 'when', not 'what'.
Add — detected, not typed
The hero interaction. A charge spotted in SMS arrives pre-filled: service, amount, cycle, even an Indian payment method like UPI. The user verifies rather than enters. This is what makes the tracker stick.
Craft
Decisions worth defending
SMS auto-detect over manual entry
The single decision that defines the product. It's harder to build and India-specific, but it removes the exact friction that kills every other tracker. Worth the complexity.
Local-first, no account
All data stays on the device. No sign-up, no server, no sync. For something reading your bank SMS, privacy isn't a feature, it's the price of trust. It also made onboarding a single tap.
Calm dark theme, one accent
A near-black surface with a single lime accent used only for what's live or actionable. Restraint keeps the numbers legible and the mood unanxious, which matters for a money app.
Share-of-spend, not budgets
The breakdown shows each category as a share of your actual total, never against a goal the app invented. It states a fact rather than implying judgement.
Built with AI
Designed and built with AI
Recurr is also a statement about how I work now. I didn't hand a spec to engineers, I built it, using Claude as a pair to move from Figma frames to a real, running Android app.
Designing in code changed the design. Spacing, motion and copy were tuned against a live build on a real phone, so every decision was tested in the product rather than approximated in a mockup. The handoff gap simply wasn't there.
Honest reflection
What changed, and what I got wrong
My day job runs the classic loop: research, flows, high-fidelity design, usability testing, then a handoff to engineering. Building Recurr myself collapsed that loop, and the difference reshaped how I now think about design, especially about when testing happens.
What changed in the process
Iteration got radically faster
There was no spec, no handoff, no waiting a sprint to see a decision in product. I could question a layout, change it, and feel it on a real device minutes later. That speed changed which decisions I made. I stopped over-thinking in static frames and started learning from the running app, where copy, spacing and motion actually live.
Constraints arrived early, on purpose
In a pure design tool everything is possible, so it's easy to design things that don't survive contact with real data or the platform. Building surfaced the constraints up front. SMS formats are messy, parsing is probabilistic, Android has its own rules. Designing inside those limits from day one made the product more honest and far more buildable than a polished mockup would have been.
Testing moved from prototype to product
Normally I test a Figma prototype, a careful approximation of the thing. Here I tested the real app on my own phone, every day, against my actual bank SMS. Bugs and awkward flows surfaced in genuine use, not a scripted task. The honest trade-off: solo, I lost the structured usability sessions and outside perspective my day job gives me. Dogfooding caught a lot, but it isn't a substitute for watching real users, which is exactly what I'd add next.
What I got wrong
I over-designed before I'd validated the core
I polished screens and edge states before proving the one thing that mattered: that auto-detection from SMS actually felt magic. I should have built the rough detection loop first and designed around what I learned. Lesson held: earn the polish, don't lead with it.
I underestimated the real-world mess
The happy path, a clean Netflix renewal SMS, was easy. Reality wasn't: bank formats vary, UPI mandates name the aggregator not the merchant, amounts hide next to 'available limit'. The interesting design work was in the messy middle, and I'd budget for that earlier next time instead of treating it as a tail case.
I let scope creep before nailing the loop
Calendar views, forecasts, categories. I reached for features before the single core loop (detect, confirm, never be surprised) was airtight. Cutting back to that loop is what made v1 ship. The discipline to say 'not yet' is a design skill I sharpened here.
Outcome
Outcome
A complete v1.0 shipped on the Play Store, with iOS on the roadmap: home overview, subscriptions with spend breakdown, a time-based calendar, SMS-assisted add, and reminders, all on-device and INR-native.
More than the artefact, it proved a way of working: a designer who can take a product from problem to shipped, owning the experience and the build at once.
What I'd carry forward
The win wasn't any single screen, it was deleting the work the user has to do. Reading what's already in their SMS, defaulting the safe choices, and asking only for a confirmation. The next version pushes that further: smarter detection, gentler nudges, an iOS release, and a home screen that earns the two seconds of attention it gets.