MPN.cc: building a catalog engineers can check
Origin
The first prototype could search for components, but it had grown into 11 application directories. Provider-specific engines, a copied quoting backend, and overlapping data stores made it difficult to tell which code owned a record. I began rebuilding it around a single catalog, with clear rules for how outside data could enter it.
Overview
An engineer choosing a component needs to answer several questions. Is this the exact part? Does its rating apply to this circuit? Is there stock at the required quantity? Can its symbol and circuit-board footprint be used in the design? Those answers usually come from different documents and suppliers.
MPN.cc brings that work into one component catalog. An MPN is a manufacturer part number. Search leads to an exact manufacturer's part, its technical data and datasheets, current supplier offers, and available design files. Engineers can compare parts and follow a specification back to its source.
My work at DNN covers the public product and the system that maintains it: catalog architecture, bulk imports, AI-assisted document analysis, search, KiCad delivery, and review tools. Much of the engineering is about deciding when the evidence is sufficient to publish a value, and what to retain when it isn't.
Constraints
Real supplier data kept exposing assumptions that worked in a small prototype.
Manufacturers appear under aliases, distributors describe the same part differently, and a suffix can change the package or ordering option. I kept catalog identity tied to the manufacturer and exact normalized part number. Search can accept looser wording, but that match cannot merge records or establish that two parts are interchangeable.
Implementation
The rebuild changed how the catalog accepts data, how engineers inspect it, and how much work the system repeats.
I reduced the 11 application directories to the API and web application. PostgreSQL became the catalog's persistent store, and I removed the in-memory fallback and copied quoting implementation. The Fastify API owns catalog decisions; the React application shares its TypeScript contracts.
Quote, DNN's separate supplier service, owns current price and stock collection. MPN requests offers for an exact part and quantity. A manufacturer's electrical limit and a distributor's available stock therefore have separate owners and update rules. I made the change in smaller steps that preserved working behavior, rather than maintaining two catalog implementations during a rewrite.
Features
Find and compare an exact component
Start with a part number or a supported technical description, refine the results, and compare specifications. Part pages keep the manufacturer, package, datasheet, and source-backed values together. Available KiCad previews and downloads carry the chosen identity into the design work.
Check purchasing conditions
Request current supplier offers for the quantity needed. The public market view adds price and availability observations with coverage and freshness information. Engineers can move from those observations to an exact part and a current quote; incomplete market coverage remains visible.
Correct and contribute data
Public corrections and company catalog submissions feed review workflows. Company files stay in a private staging area until publication checks pass. Administrators can inspect source rows, proposed technical values, and conflicts before accepting changes.
Use the catalog through software and agents
A public API exposes part search and resolution. Company and admin APIs also have MCP tools for AI assistants. Each company operation checks token permissions, the target organization, and current account access before using the same catalog services as the application.
Results
The project has delivered working public search, supplier offers, review tools, and production KiCad delivery for selected component families. The evidence supports several concrete outcomes.
- The repository's application count fell from 11 to two. The catalog uses PostgreSQL, and live quoting has one owner in the separate Quote service.
- Import plans preserve row-level decisions in fixed files. Review and resumable application no longer require millions of temporary planning rows in PostgreSQL.
- A production rollout covered 945 Yageo parts with two shared library assets and separate part exports. Verification covered all 945 database records and a sample of public downloads.
- The review release was checked in production with a real component. Canceling a conflict kept its existing values; accepting an explicit overwrite updated the public dimensions.
- A measured analysis experiment changed the implementation plan. The more expensive grouping approach stayed disabled after it introduced additional errors.
What mattered
I now judge catalog growth by what an engineer can check and use. A stored part, a published specification, and a downloadable footprint each need different evidence. The open work is measuring accuracy on unseen datasheets, reducing review effort, and proving repeat use. A larger catalog cannot answer those questions on its own.