Original Reddit post

Im working on my first project using Claude. I used to be a programmer when asp (before .net) was a thing. I have not actively coded anything in a very long time. I spent a couple of days asking Claude to help me figure out an personal app idea I had but I don’t know if this is the right way to go about it. Claude gave me the below. Is this the right approach did caude lead me astray? Thanks for any advice. Shoe Price Watch — Project Spec What this is A self-hosted Linux app that watches specific shoes on a single resale marketplace (StockX or GOAT), checks price for a specific size on a schedule, and alerts me (email or similar) when a shoe hits my target price. Controlled through a simple local web interface. Source of truth Single marketplace: StockX or GOAT (pick one to start). This one site serves two roles: Catalog — searched when adding a shoe, so I can find the exact model/colorway/size without needing a style code or juggling multiple retailers. Price source — the daily check re-visits that same product/size listing and pulls the current price. This intentionally trades off retail pricing (sometimes cheaper) for one clean, consistent catalog and price feed instead of maintaining scrapers for many sites. Known trade-offs: Prices are resale/marketplace prices, not retail — may run above or below a retailer’s sticker price depending on hype. Neither StockX nor GOAT has an official public API, so the integration is an unofficial scrape/reverse-engineered call. It can break if the site changes, and technically may run against their terms of service — an accepted risk for this project, but worth Claude Code flagging clearly in code comments in case it needs revisiting later. A second marketplace (the other of StockX/GOAT) could be added later using the same pattern, but is not part of v1. Goals (v1) Search the chosen marketplace’s catalog by shoe name (or style code) when adding a shoe. Pick the exact result + size from search results — that becomes the watched item. Set a target price for that shoe/size. App checks the price on a schedule (e.g. once a day). When price ≤ target, send me an alert and mark it as “hit” in the UI. View all watched shoes, their current price, price history, and status in a web page. Runs entirely on my own Linux machine — no cloud hosting required. Explicitly out of scope for v1 Mobile app. Multi-user support / accounts. Automatic checkout or purchasing. A second marketplace or retail sites — single source only for now. Suggested tech stack Backend + scheduler: Python (FastAPI or Flask) — easy to pair with scraping libraries and cron-like scheduling ( APScheduler ). Database: SQLite — no separate server needed, single file, plenty for this scale. Frontend: Simple server-rendered pages or a minimal HTML/JS frontend — no need for a heavy framework. Scraping/data access: requests + BeautifulSoup if the marketplace’s pages are server-rendered enough to parse directly; Playwright if it requires JS rendering. Worth a quick check for any semi-public/internal API endpoints the site’s own frontend calls, which can be more stable than parsing HTML. Alerting: Start with email via SMTP (e.g. Gmail app password). Optional stretch: ntfy.sh or Telegram bot for push-style alerts, which are simpler to set up than email in some cases. Scheduling: Either cron calling a script, or APScheduler running inside the app process — either is fine, cron is simpler to reason about. (Claude Code can swap any of these for equivalent tools if it has a good reason — this is a starting recommendation, not a hard requirement.) Data model (starting point) shoes id name colorway size marketplace_url (the specific product+size listing being watched) target_price current_price (nullable until first check) last_checked_at status ( watching / hit / error ) notes created_at price_history id shoe_id (FK) price checked_at Core features / user flows Search & add a shoe — enter a name or style code, app searches the marketplace catalog and shows matching results (with colorway/thumbnail if available); pick the right one, pick the size, set a target price. App does an initial price check right away. Dashboard — list of watched shoes with name, colorway, size, current price, target price, status badge, last-checked time. Price check job — runs on a schedule, fetches current price for each active shoe/size, logs it to price_history, updates status. Alert on hit — when a check finds price ≤ target, send an email (subject: shoe name + price) and update status so it doesn’t re-alert every cycle. Remove/edit a shoe — pause or delete a watch, or change its target price. Price history view — simple chart or list of past prices for a shoe (nice-to-have, not blocking v1). Scraping/integration notes for Claude Code to plan around Confirm which marketplace (StockX or GOAT) before starting — the search and price-fetch logic will be specific to that site’s page/data structure. Look for any internal API calls the site’s own search or product pages make (visible via browser dev tools network tab) before committing to HTML scraping — often more stable if available. Keep check frequency reasonable (once a day as planned) to avoid rate-limiting or blocks. Handle “listing no longer available / size sold out” gracefully rather than erroring out — mark status accordingly instead of crashing the check job. Isolate the marketplace integration into its own module so it can be swapped or duplicated (for a second marketplace) later without touching the rest of the app. Alerting notes Email via SMTP is the default plan — I’ll need to generate an app password for whatever email account sends these. Should only alert once per “hit” (not every check cycle) unless the price changes again. Deployment Runs locally on my Linux machine. Should be startable as a single command or simple script; a systemd service is a nice-to-have for auto-start on boot, not required for v1. Open questions to settle before/while building StockX or GOAT — which one to start with? Which email account/service will send alerts? How often should checks run? (default assumption: once daily) Any preference on port/URL for the local web UI? Suggested build order Data model + SQLite setup. Manual “add shoe” + dashboard UI (no live search yet, entered by hand) — get the UI/data flow working first. Marketplace search integration, wired into the “add shoe” flow. Price-check integration for a single watched listing, wired into a manual “check now” button. Scheduler to run checks automatically (daily). Email alerting on price hit. Price history view / polish. submitted by /u/Ill_Relationship_365

Originally posted by u/Ill_Relationship_365 on r/ClaudeCode