Why I built it
Recurr started from a problem I had myself: subscriptions were renewing around me, and the tools I found either wanted more sensitive financial access than I was comfortable giving or did not fit how I wanted to review and manage the information.
In a subscription economy where trials turn into commitments and contracts quietly keep charging, I wanted a better system than Excel sheets or Notion tables to track what I was paying for, what was worth keeping, and what was quietly renewing without turning my financial life into somebody else’s data product.
The category already had demand. Apps like Rocket Money help people find and cancel subscriptions, and that is useful. They also clarified the tradeoff I wanted to avoid. Rocket’s own security page describes bank-linked transaction access through Plaid or Akoya, its FAQ says hands-off cancellation is part of Premium, and EPIC filed a CFPB complaint in 2022 alleging misleading privacy and fee design. I did not want the first useful version of Recurr to require full bank-linking, opaque automation, or a user guessing what happens after they hand over access.
After more research, the personal problem looked less personal. CNET’s 2025 subscription survey reported that US adults spend about $1,080 per year on subscriptions on average, including more than $200 per year on unused ones. People lose visibility, procrastinate because the audit is tedious, and keep paying for services they forgot about. I know that first hand, because I had experienced it myself.
That need eventually led to the core product objective: find recurring charges from limited, user-chosen inputs while keeping the results explainable, easy to review, and economical enough to run. Recurr’s job is to turn scattered subscription signals into a clear view of what is active, what may be wasteful, and what needs attention, without making manual review the default experience.
Why this matters. Subscription tracking is a trust problem as much as a categorization problem. The product has to earn trust before it asks the user to share anything, detect likely subscriptions on its own, and make uncertain findings clear enough to verify, correct, or act on when needed.
Recurr accepts user-provided information, detects subscription signals, lists high-confidence subscriptions automatically, and asks for review when a finding needs human judgment.
What I built
Recurr is a TypeScript pnpm monorepo with a React and Vite PWA frontend, an Express and TypeScript backend, and a shared package for cross-surface types. The backend is organized by business domains rather than technical folders, with ESLint boundary rules to keep domain code from drifting into a single mixed service layer.
Recurr accepts user-provided information, turns it into subscription signals, and uses confidence to decide what can be listed automatically and what should stay in review. The engineering shape is visible in the product boundaries: input handling, signal normalization, AI-assisted review, billing, auth, observability, and launch controls.
Build areas
Product, platform, and AI cost control
The product has to feel simple for the user while keeping billing, detection, AI cost, and operational controls separated underneath.
Product judgment
A user flow that makes automatic detection understandable, with review where the product needs human judgment.
Backend boundaries
A TypeScript backend organized by business domains, keeping identity, billing, records, user inputs, and AI-assisted work in separate lanes.
AI cost discipline
AI is reserved for the work that benefits from interpretation. Deterministic logic handles the parts that should stay cheap, predictable, and testable.
Launch controls
The product includes auth, billing, observability, rate-aware operations, secrets handling, and tests around the paths that need production discipline.
The AI layer
The AI layer carries some of the main engineering weight, but it is not a simple thin wrapper around a model call. The orchestration is designed to decide when interpretation is useful, when predictable logic is enough, and when a result should become an automatic finding or stay in review.
That design changes the product economics. Each detection path has to balance usefulness, confidence, cost, and user trust before it becomes part of the product experience.
The result is an AI layer treated like production infrastructure: bounded, observable, and designed to stop early when a detection path is uncertain or too expensive.
Hard-won lesson. AI-assisted SaaS work is mostly failure-mode and cost control. If a task is retried without limits, a small review problem can quietly become an expensive one.
Product and data boundaries
The product boundary is built around minimum useful access. Recurr should not need broad financial visibility just to start helping a user understand recurring charges. User-provided information enters through controlled surfaces, high-confidence findings can become subscription records automatically, and lower-confidence findings stay easy to review or correct.
The same boundary discipline runs through the product internals. Identity, subscription records, billing state, user input handling, and AI-assisted processing stay separated so privacy, cost, debugging, and future compliance do not depend on one mixed service doing everything.
Working scope
Recurr is currently a private alpha. The public surface at recurrapp.com is the waitlist, while the product implementation remains closed.
I can discuss the architecture, selected implementation details, or a guided walkthrough on request.