Inspiration
We both had the same problem: a pile of monthly charges we'd stopped paying attention to. When we actually looked, a lot of those services offered a cheaper tier that would've been fine for us. We just never checked, because comparing plans is tedious and changing them is buried three menus deep in account settings.
That got us thinking about what an AI agent could take off your plate. Finding a better plan is only half of it. The part people actually skip is making the change. So we set out to build something that does both, while still asking you before it touches anything.
What it does
ReDeal keeps a list of everything you pay for each month. You can enter subscriptions yourself, or pull one in directly from PayPal, where we read the current plan and price through PayPal's Subscriptions API.
When you run a scan, ReDeal handles the two kinds of subscriptions differently. If a plan is billed through PayPal, it looks at every plan that merchant offers in their PayPal catalog and has OpenAI compare the cheaper ones against yours (same features? any eligibility requirements? anything you'd lose?). For everything else, it searches the web for current offers, and a separate verification step confirms the price, billing period and availability before anything gets shown to you. If an offer can't be verified, we drop it.
The results show up as cards you swipe through, sorted by yearly savings. Each one shows the price difference, who qualifies, the trade offs, and a short explanation from the model. Offers that come with conditions, like student pricing, are marked so you don't get surprised later.
Approving a PayPal deal sends a plan change request to PayPal. You approve it on PayPal's site, you're redirected back, and ReDeal re checks the subscription with PayPal to make sure the change actually went through. If you regret it, you can undo it, which sends PayPal the reverse request.
We also didn't want the app to inflate anything. All savings are calculated by our code, not by the model, and we show estimated savings separately from confirmed ones. Confirmed savings stay at zero until a cheaper payment actually happens.
It all runs in PayPal's sandbox, so it's test money only. For judges, there's a Load Sample Data button that fills the app with a few common subscriptions plus a PayPal sandbox subscription, so you don't have to set anything up.
How we built it
The backend is Python and FastAPI, with SQLAlchemy on top of SQLite for local development and PostgreSQL in production on Render.
For PayPal, we authenticate with client credentials and use three parts of the REST API: Catalog Products, Plans (to list a merchant's plans and their prices) and Subscriptions (to create, read and revise them). When we request a plan revision, we pass return and cancel URLs so the user comes back to ReDeal after approving.
For the AI side, we use OpenAI's Responses API with gpt-5.1. One prompt researches offers using web search, a second one independently reviews each result, and a third compares plans within a PayPal catalog. We force every response into a strict JSON schema, which made the output much more predictable, and all prices are handled as whole cents in Python.
The frontend is vanilla HTML, CSS and JavaScript. We wrote our own spring animations for the card swiping because the default transitions felt stiff. Deployment is a Render Blueprint, and the hosted site sits behind a password, with all API keys kept server side. We have a pytest suite as well, including a test that runs the whole PayPal flow against a fake PayPal API.
Challenges we ran into
Our first version trusted the model too much. It would report prices that were out of date or flat out made up, with total confidence. Adding a second review step, enforcing JSON schemas, and writing explicit rules (for example, a family plan's per person cost should never be compared to an individual plan) cut that down a lot. For PayPal plans we went further and stopped asking the model about prices entirely, since PayPal's catalog already has them.
Getting real plan changes working took longer than we expected. PayPal makes the buyer approve a revision, so we had to deal with the redirect flow, handle both the approve and cancel cases, and sync with PayPal afterwards instead of assuming success.
Making the demo work for a group of judges was its own problem. Everyone shares the same sandbox subscription, so one person's change affects the next person. We added a reset that restores the sample data and, if the subscription was already switched, asks PayPal to move it back.
Smaller things ate time too: a race condition that occasionally imported the same PayPal subscription twice, and our antivirus software intercepting HTTPS traffic, which made API calls fail in confusing ways until we figured out what was happening.
Accomplishments that we're proud of
The whole thing works end to end: the AI finds a cheaper plan, you approve it, PayPal makes the change, and ReDeal confirms it. We're also happy that the savings it reports are realistic, and that someone can try the full experience in about a minute with zero setup.
What we learned
We got very familiar with PayPal's subscription APIs, especially how plan revisions and buyer approval work in the sandbox. We learned that language models are good at reading between the lines of a plan description, but they shouldn't be the source for numbers. And we found that asking for the user's approval at each step didn't slow the experience down; it made people more comfortable letting an agent act for them.
What's next
- Letting users log in with PayPal and import all of their real subscriptions, not just one sandbox demo
- Using PayPal webhooks to confirm plan changes automatically and track actual savings once a lower bill is paid
- User accounts, scheduled scans, and alerts when a service changes its prices
Built With
- css3
- fastapi
- gpt-5.1
- html5
- javascript
- openai
- openai-responses-api
- paypal
- paypal-subscriptions-api
- postgresql
- python
- render
- sqlalchemy
- sqlite
