How the watch works.

Why this exists

Hardware teams still run important BOM risk checks through spreadsheets, inboxes, and memory. ShareCo exists because one missed lifecycle notice can burn more time than a team spends watching the whole BOM for a year.

What we built

The v1 system is intentionally boring: upload BOM, normalize parts, connect official distributor sources, schedule daily checks, diff the results, and alert when the risk profile changes.

bom_upload -> parse_parts -> distributor_watch
  -> daily_diff -> classify_risk -> alert_digest

Distributor API choices

Digi-Key and Mouser are first because they offer sanctioned APIs and enough coverage for the first customer profile. Nexar and Octopart stay deferred until the product proves the need.

• No scraping distributor websites.
• No raw distributor data redistribution.
• Caching windows stay inside distributor terms.

The watching engine

Durable jobs run the watch loop so a transient distributor or network failure does not erase a day's check.

inngest.schedule('daily-bom-watch')
  .fanOut(org.boms)
  .retry(distributor.check)
  .emit('bom.risk.changed')

The alternates engine

Parametric filters produce the candidate set. GPT-5.5 ranks and explains the shortlist in language an engineer can reject quickly.

Caching and rate limits

ShareCo caches only the derived watch state it needs to explain alerts. Pricing and stock snapshots are never treated as permanent catalogue data.

Where we do not use AI

AI does not decide what to buy, write to accounting systems, contact vendors, or invent missing distributor facts. If source data is incomplete, the alert says so.

Open questions and what is next

The next open questions are customer-driven: which distributor matters after Mouser, what teams need from Slack alerts, and whether cost roll-up belongs before inventory tracking.

Try it

The fastest way to test the architecture is to upload a real BOM and see whether the first watch catches something your spreadsheet missed.