Oprocon
B2B machinery marketplace and consultant management, German market
- State
- Status: Live
- Role
- Lead developer
- Year
- 2025
- Stack
- Laravel
- Vanila JS
A German-market platform covering two sides of industrial machinery: a marketplace catalogue fed by an assisted ingestion pipeline, and management of the consultants who work the deals. Ingestion runs from an allowlist-driven source registry with a per-supplier state machine, and AI-normalised records are held for human review before they can publish.
The problem
Industrial machinery inventory lives on hundreds of supplier sites in whatever format the supplier chose, mostly free-text specification sheets. A buyer comparing two lathes is comparing two documents written to different conventions. Making that inventory searchable means normalising it, and normalising it means ingesting from sources that break constantly. The platform covers both halves of the business: the catalogue, and the consultants who work the deals against it.
Constraints
- German client under GDPR, so outbound email needs consent and suppression handled properly rather than as a footer link.
- Ingestion is only permitted from sources the client has explicitly agreed to.
- Specification sheets are free text with no shared vocabulary between suppliers.
Architecture
A Laravel application spanning the machinery catalogue and the consultant side of the business. Ingestion is driven by a source registry: each permitted supplier is a registry entry carrying its own fetch configuration, parsing rules and schedule. Each supplier runs its own state machine, so a stuck source is visibly stuck rather than absorbed into a shared pipeline status. Extracted records are normalised with AI assistance and land in a review queue before they can publish. Outbound email checks consent and suppression at send time.
Decisions and what they cost
Drive ingestion from an allowlist source registry rather than open crawling.
- Why
- Open crawling is a legal exposure in this jurisdiction and an operational one everywhere: an unknown source is a source nobody has agreed to support. A registry makes adding a supplier a deliberate act with a named owner and a config.
- What it cost
- Coverage grows at the pace of the agreements, so the catalogue can never outrun the commercial relationships.
Give every supplier its own ingestion state machine.
- Why
- Sources fail differently: one changes its markup, one starts rate limiting, one goes dark for a week. A shared pipeline state tells you the pipeline is unhealthy. A per-supplier state tells you which supplier, in what way, since when.
- What it cost
- More state to model, persist and observe, and a dashboard that has to make dozens of independent state machines legible at a glance.
Put AI-normalised records in a review queue instead of publishing them.
- Why
- Extraction from free-text specification sheets is right most of the time and confidently wrong the rest. In machinery, a wrong tolerance or capacity figure is an expensive purchase decision made on our data.
- What it cost
- A human review queue is now a permanent operational cost that scales with catalogue growth, not a temporary bootstrap measure.
Check consent and suppression at send time, not at list build time.
- Why
- A list built on Monday and sent on Thursday can contain a withdrawal made on Tuesday. Under GDPR the check has to happen at the moment of sending or it is not a check.
- What it cost
- Every send does per-recipient lookups, which makes large sends slower and puts the suppression store on the critical path of outbound delivery.
What it does
Source registry
Every permitted supplier is a registry entry with its own fetch config, parse rules and schedule. Nothing is ingested from a source that is not in the registry.
Per-supplier state machines
Each source advances through its own states, so failures are attributable and a single broken supplier does not read as a broken pipeline.
Review before publish
AI-assisted normalisation produces candidates. A human promotes them. Nothing reaches the catalogue unreviewed.
Consent checked at send
Outbound email resolves consent and suppression at the moment of delivery, so a withdrawal between list build and send is honoured.