Case study · Automated sourcing system
Automating the search for underpriced listings.
The family business already knew how to buy and resell profitably. The limiting factor was sourcing. I built a market intelligence engine that scans the national market, classifies listings, estimates relative value from observed market references and ranks opportunities against configurable margin thresholds. It runs continuously across several verticals.
The system, in production
Production snapshot · 1 Sep 2026. A screenshot of the real control panel, which refreshes every few hours across four verticals. Figures are system throughput, not trading margins.
Coverage · auto-classification per vertical
Before scoring, the system removes 115,545 irrelevant records and flags 1,684 suspicious or broken records for exclusion or review. The remaining data is retained for classification, valuation and ranking.
In resale markets, an attractive listing only becomes useful when it can be compared quickly with reliable market references. Doing that manually across thousands of new listings every week does not scale.
The system handles the repetitive part: collecting listings, classifying them, comparing them with observed references and prioritising the small subset that deserves manual review.
The pipeline runs automatically from collection to classification, valuation, ranking and alerting. The production implementation remains private.
| Capture at scale | Continuous national market scanning across multiple sources and verticals, with persistent collection and deduplication. |
|---|---|
| Relative valuation | Compares each item with observed market references rather than relying on the seller's asking price alone. |
| Opportunity ranking | Scores listings against configurable thresholds so the strongest candidates reach the top of the review queue. |
| Alerts | Sends shortlisted opportunities to mobile with the relevant valuation context and target price for manual decision making. |
Collection was straightforward. Reliable valuation was harder because marketplace data is noisy, incomplete and often mispriced. The first version produced too many false positives.
The next iterations focused on identifying distorted references, improving data quality and recalibrating the scoring rules. The result was a much smaller review queue, with each candidate supported by market references and a configurable margin threshold.
Precision matters more than the number of alerts. A smaller set of well-supported candidates is more useful than a large list of false positives.
The core pipeline stays the same; sources, classification rules and valuation logic change by vertical.
The system separates the reusable pipeline from the rules that are specific to each market. New verticals mainly require a new source, classification logic and valuation model.
Reusable pipeline
Collection, deduplication, classification, valuation, scoring and alerting follow the same core workflow across categories.
Vertical-specific rules
Each vertical has its own classification and valuation logic, including cases where component value matters more than the whole item.
New verticals
The same architecture can be adapted to other sourcing problems where structured market references and ranking criteria are available.
On top of the pipeline runs a local LLM agent (Qwen through Ollama, on my own server, with no cloud APIs and no data leaving the machine) that answers questions over the database in plain language: what a part is going for right now, where it is cheapest, how many sold last month, whether a listing is a good deal.
| Typed tools | The model receives a catalog of typed tools (search listings, count, median price, opportunities) and decides which to call and with which arguments. It never sees the schema and never writes a query. |
|---|---|
| Validation | Every argument is checked against a whitelist before anything runs, so an invented column or value is rejected instead of executed. |
| Read-only execution | Hand-written parametrized SQL runs as a read-only database user and returns rows to the model, which writes the answer from real data. |
| Operations | Run like production software: a watchdog with 20+ checks, tested backups and a fail-closed job queue with retries. |
Fixed query catalog
The model only picks a query and extracts parameters. Safe but rigid: every new question needed a new query.
Model writes SQL
Contained by a read-only role. Flexible, but it invented columns and figures and the output could not be trusted.
Typed tool calling
The approach in production. Same flexibility as free SQL, with no code path where the model writes a query.
The model decides what to ask; the code decides what is allowed to run. Three patterns were built and compared in production before settling on this one.