Inspiration
Player-driven marketplaces are often thin, noisy, and difficult to evaluate. A listing may look cheap compared with the current market, but it can still be a bad opportunity if prices are falling, liquidity is low, transaction costs are high, or the available data is incomplete.
I built ROZ CheapFinder because I wanted a system that could do more than report the lowest price. It should preserve market evidence, compare current listings with historical observations, and explain whether an apparent discount is actually worth acting on.
What it does
ROZ CheapFinder is a marketplace monitoring and decision-support system for thin and noisy markets.
It:
- Collects current listings and historical price observations
- Matches items using exact names and controlled fallback matching
- Compares current prices with 1-day, 7-day, and 30-day market history
- Estimates transaction costs and potential profit
- Evaluates price trends, data quality, liquidity, and competing listings
- Produces automated alerts and evidence-backed recommendations
- Stores observations for reproducible analysis and backtesting
- Provides a visual interface for reviewing monitored items, signals, system health, and historical results
The system can also abstain from making a recommendation when the available evidence is insufficient or contradictory.
How I built it
The project is primarily built with Python, Playwright, SQLite, and a browser-based monitoring interface.
The architecture separates three different types of state:
- A short-lived watch cache for recent marketplace queries
- Alert state for notification control and duplicate prevention
- A long-term observation store for research, replay, and backtesting
A query scheduler controls historical-data requests and prevents unnecessary repeated queries. The signal engine combines current listings, historical prices, transaction costs, trend information, and data-quality checks before deciding whether an opportunity should be reported.
The project also includes a recorded-data backtest mode, allowing the analysis pipeline to be tested without depending on a live marketplace.
During OpenAI Build Week, I am using Codex and GPT-5.6 to improve the reproducible demonstration workflow, recommendation auditability, replay-based testing, documentation, and judge-facing product experience.
Challenges I ran into
The largest challenge was distinguishing a genuine opportunity from a misleading low price.
Thin marketplaces frequently contain sparse observations, inconsistent item names, stale listings, temporary price shocks, and individual outliers. A simple percentage-discount rule generated too many unreliable signals.
Another challenge was reproducibility. Live marketplace data changes continuously, so debugging an earlier recommendation is difficult unless the exact listings, historical observations, configuration, and decision output are preserved.
I addressed these problems by adding data-quality gates, controlled matching rules, historical observation storage, query budgets, explicit abstention states, and recorded-data backtesting.
Accomplishments that I'm proud of
I am proud that the project has evolved from a simple price watcher into a complete monitoring and analysis pipeline.
The system now maintains long-term marketplace observations, evaluates opportunities using multiple evidence sources, controls notification quality, supports reproducible backtesting, and exposes its decisions through a visual interface.
I am also proud that the system does not force a recommendation. It can clearly report when more data is required, which makes the output more reliable and easier to audit.
What I learned
I learned that marketplace monitoring is not mainly a price-comparison problem. It is a data-quality and decision-making problem.
A useful system must explain why a signal exists, identify contradictory evidence, preserve the inputs that produced the decision, and recognize when it should not make a recommendation.
I also learned that separating live collection, decision state, and long-term research data makes the system significantly easier to test, maintain, and improve.
Log in or sign up for Devpost to join the conversation.