Case study · Pharomatcher
A tiered matching algorithm for bilingual catalogs
Bilingual supplier catalogs matched against a master record, ending in procurement recommendations instead of a score dump.
stack
python · fastapi · mysql · next.js · docker · terraform
model
multi-tenant
status
in production
- 4
- matching stages, exact to human review
- 2
- languages normalized in every catalog
- 1
- server running the entire platform
The situation
Suppliers send catalogs as files: thousands of rows, two languages, inconsistent names, and prices that moved since last month. Matching them against a master record by hand eats days and still misses duplicates.
What we built
Suppliers and staff upload files through web dashboards. The core application normalizes every row, indexes prices, and runs tiered matching: exact first, then fuzzy similarity, then an external AI service when one is configured, with low-confidence pairs routed to human review.
What comes out the other end is procurement recommendations and dashboards that show which price differences are worth acting on.
Recommendations, not a score dump.
How it runs
Each customer’s records live in a separate database on one MySQL instance, and the whole platform runs on a single Hetzner server. AWS handles optional file conversion and scheduled backup storage, and an integration adapter syncs with the customer’s legacy ERP where one exists.
Next case study · Tunnel Hub
Office software, reachable from anywhereOne VPS that puts remote employees inside office software that was never built for the internet.