Built Different exists because the highest-leverage problems for specialty manufacturers almost always live between disciplines — and the people set up to solve them rarely have time, scope, or tooling to cross the seam.
The trajectory started in mechanical engineering — CAD oriented work, then time as a Systems Engineer at a specialty manufacturer, day-to-day work touching CAD vaults, ERP transactions, photometric data, and the applications people use on the production floor.
That work kept surfacing the same pattern: the problems with the most leverage rarely live inside any one discipline. They live at the seams. CAD ↔ ERP. Engineering judgment ↔ operations workflow. Hardware capability ↔ what the catalog says it does. Photometric measurement ↔ BIM specification. The seam is where the bottlenecks are, and it's where most of the bespoke work that would actually pay back goes undone — because the people on either side aren't quite set up to do it.
Built Different exists to do that bridging work. For specialty manufacturers who need it, but don't have a full software team — and don't want one.
The work, again and again, is the same act: take what an engineer knows, document and encode it so the next person doesn't have to relearn it.
Most ERP and CAD systems are powerful but built for generality — your team ends up clicking through forms designed for someone else's process. We build lightweight web apps tailored to your existing workflow, wrapping cumbersome systems (Epicor Kinetic, SOLIDWORKS PDM, and similar) into role-specific tools that only show the inputs, lookups, and confirmations the job at hand actually requires.
Quotes and submittals slow down when every customer-facing deliverable — IES file, Revit family, programming spec — has to be hand-built by an engineer. We automate that pipeline end-to-end, generating the full spec package from product configuration. Built on photometric modeling that reconciles measured fixture data with component-level output, and IES parsing/validation across LM-63-2002 and LM-63-2019.
Architects and electrical engineers expect to drop your product into a Revit model and have it just work. We build the family-generation pipelines that make that real: parametric Revit families, MEP shared-parameter standards across the catalog, and Autodesk Platform Services workflows that turn each product configuration into specifier-ready BIM content. Type-catalog architecture decisions made deliberately rather than by accident.
Every manufacturer has a list of tools they wish existed but can't justify purchasing — production interfaces, configuration helpers, in-context operator UIs, internal dashboards. Built with React, Node, TypeScript, and SQL, these apps are tailored to your processes and pay back the day they ship.
Vendor documentation and the actual hardware rarely fully agree, and the SDK in between often does its own thing. Someone has to encode the difference into something the production line can rely on — that reconciliation, written into production code, is most of what vendor toolchain integration actually is.
The database is what actually runs your business; the form layer and documentation often disagree about what it's doing. We build the reports, validation tooling, and operational dashboards that surface what the UI hides — so decisions get made on the source of truth rather than on what a screen happens to display.
On the software side, the stack spans React, Node.js, TypeScript, SQL Server, C#, and REST API design. On the engineering side, the work crosses ERP systems for transactional records and operational data (Epicor Kinetic, with patterns that transfer to similar platforms), PDM systems for engineering file control (SOLIDWORKS PDM), CAD platforms for modeling and macro automation (SOLIDWORKS, Solid Edge), and BIM platforms for specifier-side deliverables (Revit, with Autodesk Platform Services behind the family-generation pipeline). The day-to-day work spans both sides.