Selected work

Four projects, four bridges between engineering and software.

These projects share a through-line: the highest-leverage work for a specialty manufacturer almost always sits between disciplines — between CAD and ERP, between technical data and customer-facing deliverables, between engineering judgment and the operations floor. Each one, in its own way, takes knowledge that lived in spreadsheets or people's heads and encodes it into something anyone on the team can use.

Names, schemas, and specific vendor toolchains are kept generic by design.

§ 01

Case studies

01 / 04

IES-to-Revit family automation via Autodesk Platform Services

RevitAutodesk Platform ServicesMEPIES (LM-63)

When a specifier configures a fixture on a lighting manufacturer's website, the site generates a complete Revit BIM family automatically and packages it into the downloadable spec sheet — no manual file generation by engineering, no email request to the catalog team. Behind the scenes: an end-to-end pipeline built on Autodesk Platform Services that ingests IES photometric files and generates parametric Revit families on demand, triggered by the configuration event, for a specialty architectural lighting manufacturer's full catalog.

The architectural decision worth dwelling on is type catalogs versus per-variant families. Generating one .rfa per optic/driver combination is straightforward but produces thousands of nearly-identical files. The alternative — one shared RFA per optic group plus a .txt type catalog enumerating photometric variants — is dramatically leaner, but it requires careful MEP shared-parameter design so downstream Revit users see the right electrical and identity data regardless of which variant they place. Most of the work, in other words, isn't generating geometry; it's deciding which parameters live on the family, which live on the type catalog row, and which belong in a separate IES reference.

Adjacent research: standardizing MEP shared parameters across the manufacturer's catalog so families behave consistently when loaded into specifier projects.

02 / 04

Photometric calculator and data pipeline

ReactNode.jsSQL ServerIES (LM-63)Photometric modeling

A configurator that lets sales or engineering pick a target output (lumens per foot) for a luminaire, then computes — end to end — exactly which board-and-driver combination produces it. The output is the full spec package: a programming spec for the driver, an IES file for the photometric simulation, and a Revit family for the BIM submittal. What used to be an engineer's judgment call, supported by a spreadsheet and a phone call, becomes a tool anyone on the sales or design team can run.

Behind the scenes, the system parses IES files (LM-63-2002 and LM-63-2019), reconciles measured fixture efficacy against modeled component output to back out a loss factor, inverts that factor to select the components matching the demand, and scales the candela distribution accordingly.

The non-obvious work isn't the file output. It's encoding the manufacturer's optical and electrical assumptions explicitly in code, rather than letting them live in spreadsheets and people's heads. The IES files are the side effect; replacing tribal knowledge with a deterministic tool is the actual deliverable.

03 / 04

Customer-shaped overlays for Epicor Kinetic and SOLIDWORKS PDM

Epicor KineticSOLIDWORKS PDMREST APIReact

Epicor Kinetic is powerful but cumbersome. Out of the box, operators click through forms built for someone else's workflow, inside a UI designed to expose every transaction the system can perform — most of which they don't need. Built Different wraps the Epicor REST API in lightweight web applications shaped to a manufacturer's actual processes: just the inputs, lookups, and confirmations the role at hand requires, with the unrelated screens stripped out. The ERP keeps doing what it does well; the people on the floor get an interface they'll actually use.

On the CAD side, SOLIDWORKS PDM holds the file truth — but the leverage is exposing those files where they're actually needed. That can mean a part-number lookup inside an internal app that surfaces the latest controlled drawing without anyone opening PDM at all. It can also mean embedding PDM-controlled files directly into production-floor work instructions or assembly-build pages, so the engineering data is visible at the moment of use rather than two clicks and a vault search away. Same integration pattern, different surface.

The unifying idea: vendor systems are built for generality, but the leverage is in fitting them to the people and workflows that already exist around them. A workflow is institutional knowledge; the right interface is that workflow encoded into something operators can lean on rather than memorize. The right interface isn't the one with every feature — it's the one shaped to the work.

04 / 04

Parametric CAD automation for an industrial OEM

Solid EdgeC#Parametric automationCAD migration

An industrial OEM in baggage-handling needed to migrate roughly 100,000 sheet-metal parts from AutoCAD into Solid Edge. Each base part had around ten length variants, and each variant required an individually rebuilt configuration and drawing — repetitive, error-prone, and at that scale, mathematically infeasible on the schedule available.

The leverage point: a parametric Solid Edge macro in C# that took a base part, accepted a length parameter, and generated scaled configurations alongside drawings auto-cloned from a base drawing template with the correct configuration references.

Workload dropped roughly tenfold; the migration completed on schedule. The macro itself was the deliverable — engineering knowledge of how length parameters drive geometry, encoded once so it didn't have to be repeated 100,000 times.