Inspiration

Every fast food chain wants you locked into its own loyalty app. McDonald's, Wendy's, Burger King, Pizza Pizza, each one with a separate signup, a separate password, a separate login screen. Customers just want the discount. Nobody wants to manage six apps to get one. So people give up, miss deals, forget which app had which coupon, and the points just sit there unredeemed. There's no way to build around this with an API either, because there isn't one. Not one major Canadian chain publishes its deals or rewards data. The information exists, it's just locked behind each brand's own website or app. That's a browser problem, which is exactly what Steel is built to solve.

What it does

Munchie puts every fast food reward and offer in one place, and does the tedious part for you. Featured coupons pulled live from brand websites, including offers that only appear once you're signed into an account. Our agents log in and make sure you're always seeing the real price. A rewards wallet holding every account we've linked, with a real login behind each one, not a mockup. Homepage dashboard that pulls the best available offers together and ranks them, so the useful deals surface instead of getting buried in marketing copy. Order ahead, using each restaurant's own native delivery system instead of paying a markup through a third party app.

How we built it

Two people split the work and merged it into one project. The agent runs four tools per brand. Snapshot loads the page and clears cookie banners and popups. Extract pulls out offer-like text while filtering out legal fine print, navigation bars, and FAQ copy. Report scores each offer with plain rules you can read. Structure sends the scored text to Claude, which returns clean records with a price, a category, searchable tags, and a value score. The first three tools are the loop shape from the Steel workshop. The fourth is the part plain rules can't do. It reads "McValue Small Meals are now $5 each plus tax" and understands that's a five dollar burger combo, pickup only, worth tagging for search. A separate agent handles real accounts. For brands with a signup flow, it fills out the form the same way a person would, verifies the email through IMAP, and once it's in, reads whatever only appears behind that login. For Burger King specifically, that surfaced eight offers a logged out visitor would never see. One Steel session covers every public brand, since runtime is what Steel actually charges for. A full run across three brands costs under two cents. Routing through a Canadian IP mattered more than expected. Steel's default IPs are American, and Canadian restaurant sites behave differently when a request looks foreign.

Challenges we ran into

Most Canadian fast food rewards have no web login at all. We tested several chains directly. McDonald's states outright that rewards require their app. Tim Hortons emails a one-time code instead of a password, which an agent can't complete without inbox access. Some brands do have real signups, and those are the ones we built working flows for tonight. That was frustrating to discover mid-build, but it turned out to be the actual insight behind the whole project. This data has never been aggregated because it's deliberately locked inside separate apps. Overlays were most of the actual engineering work. Restaurant sites throw cookie banners, location pickers, and consent modals over everything, and they load in late. One popup alone caused about twenty failed clicks before we built a proper handler for it. The fix checks for a real close button first, falls back to pressing escape, and if the popup is still there, removes it directly. Signup flows branch in ways a fixed script doesn't expect. A live account creation can land on a different screen depending on what the site decides to show that day. We built a small model-assisted fallback that reads the page and decides the next click when our scripted steps don't match what's actually on screen. Turning scraped marketing copy into something searchable. A phrase like "$6 Nuggets + Medium Fries" needs to become a price, a category, and tags before it's useful. Getting consistent structured output required a strict schema and cleaning up encoding issues in scraped text along the way.

Accomplishments we're proud of

A real four tool agent loop producing structured, comparable offers across brands that format nothing the same way. An agent that creates a genuine account, verifies it by email, and pulls back data that literally does not exist for a logged out visitor. Honest scoping throughout. Every account and every offer in the app is either real or clearly marked as not yet linked. The full public deals run costs under two cents.

What we learned

The hardest problem wasn't scraping, it was discovering the actual shape of the constraint. We assumed most rewards programs would have some kind of web presence, and found out through direct testing that app-only is the norm, not the exception. That reframed the whole project from "aggregate an API" into "there is no API, and that's exactly the opportunity." We also learned that agent reliability mostly comes down to handling everything standing in front of the thing you actually want, popups, redirects, verification steps, rather than the core action itself.

What's next

Per brand credential swapping. Right now Munchie uses one set of credentials across every platform it signs you up for, for simplicity. The next step is letting users override that per brand, so if they already have a long standing account somewhere with saved points, they can plug in that specific login instead of getting a brand new one, and generate a unique password for any account they're worried about. Mobile emulation for the app-only tier, which is most of the market right now. Handling texted verification codes, not just emailed links, which would unlock brands like Tim Hortons. Shipping the cost control we designed, refreshing a user's deals once a day or when they've moved somewhere new, instead of running on demand. A vision based agent that reads the page the way a person would instead of hunting for exact element IDs, so a brand redesigning their site doesn't break the flow. Delivery price comparison, showing what a native order saves against a third party delivery app on the same order.

Built With

  • account-signup
  • browser-profile-persistence
  • burger-king-royal-perks
  • canada
  • claude-haiku
  • deal-scraping
  • express.js
  • fastfood
  • imap-email-verification
  • loyalty-rewards
  • node.js
  • playwright
  • restaurant-deals
  • steel.dev
  • store-locator
  • web-automation
Share this project:

Updates

Submission history