There's a CNC machine on the second line of a Midwest fabrication shop that cost more than the building it sits in. Zip-tied to a pillar next to it: a clipboard with the paper traveler for every job. The $400,000 machine reports its status to no one. The clipboard is the system of record.

And then there's Dave. Nineteen years on line 3, and he knows the press jams on humid days, Tuesday's delivery is always short, and the ERP's inventory count is "aspirational." The shop's real intelligence lives in Dave and an MES from 2004 nobody dares reboot.

Manufacturing custom software from an embedded engineer starts here: not a gleaming smart-factory rollout, but one person sitting next to the clipboard, learning why it exists. The playbook below is how the good engagements begin, roughly in order.

The Clipboard Next to the CNC

Every factory has a clipboard. Sometimes it's literally a clipboard; sometimes it's a whiteboard, a shared Excel file called FINAL_v7, or a group text. The pattern is the same: the official systems capture some of the truth, and an informal layer captures the rest, and the informal layer is the one people actually trust.

An FDE's first job is not to replace the clipboard. It's to understand what the clipboard knows that the systems don't. That gap, the distance between official data and trusted data, is the entire opportunity map for the engagement. Everything you build in the first quarter lives somewhere inside it.

What the Floor Actually Looks Like

Set your expectations correctly. A typical 50-to-300-person manufacturer runs something like this:

None of this is stupidity. It's archaeology. Each layer was the right decision at the time, and the layers never got consolidated because production never stops long enough to let you. An embedded engineer who walks in sneering at the stack will learn nothing. The one who walks in curious will learn everything.

Weeks One to Four: Where an Embedded Engineer Starts

Week one is shadowing. Not interviewing, not workshopping: standing next to operators through full shifts, including the 5 a.m. one, because the night shift is where the unofficial process lives. You're watching for one thing above all: retyping. Every time a human copies a number from one screen or sheet into another, you've found a place where the business is paying a person to be a slow, error-prone integration.

Say you find that the shift supervisor spends 90 minutes every morning building the day's production report from three systems and a phone call. That's your first build, and it tells you the universal rule of manufacturing engagements: the first build is always visibility. One dashboard that shows what the floor is doing right now. Not predictive analytics, not AI, just a screen that answers "are we winning today?" without the 90 minutes of archaeology.

This works for two reasons. It's obviously useful, so operators tolerate the next, more invasive builds. And it forces you to solve the data-collection problem early, which is the hard part of everything that follows. We've seen the same visibility-first pattern pay off in other paper-heavy industries; the logistics FDE playbook is nearly the same story with pallets instead of parts.

Machines Without APIs: Getting Data Anyway

"But our machines are too old to connect" is the most common objection, and it's almost always wrong. It's just a ladder of decreasing elegance:

One shop I worked with instrumented eleven machines for under $900 in hardware, because only two of them warranted real integrations. The dashboard didn't care that eight of its data sources were clamps. Neither did the morning meeting.

Tribal Knowledge Into Software

Now back to Dave. Dave is the risk and the prize: he holds two decades of process knowledge, and he's watched three software initiatives come and go without asking him anything. Interview him wrong and you'll get shrugs. The trick is to interview him about stories, not rules. "Tell me about the last time line 3 ruined your week" gets you the humid-day rule, the short-delivery pattern, and the upstream cause of the quality spike, all in one answer.

Then encode what you learn as assistance, not replacement. The humid-day rule becomes an alert: "humidity above 70%, check the feed tension on the press." The alert doesn't run the machine. It makes a newer operator slightly more like Dave. That's the whole game, and framing it that way is what turns Dave from the engagement's biggest skeptic into its co-author. People who feel replaced break your system in creative ways. People who feel amplified defend it.

The Plays That Pay Back

After visibility, the builds with the fastest payback, in rough order:

  1. Downtime tracking with real reasons. Once the floor can see downtime as it happens, the weekly blame meeting dies. The argument shifts from "whose fault" to "which cause, and how do we remove it." One shop cut unplanned downtime from about 14 hours a week to 6 in a quarter, mostly by discovering that a third of it was waiting on material staging.
  2. Changeover timing. Just measuring it, visibly, tends to improve it by 10 to 20 percent before you change anything else. Stopwatches are a miracle nobody wants to believe in.
  3. Quality traceability. When the auditor asks which lots went into which shipment, and the answer used to be a day of binder-flipping, a lookup screen pays for itself in one audit.

Typical payback windows on these run three to nine months for a mid-size shop, with visibility and downtime tracking at the fast end. The economics rhyme with the ones we mapped for document-heavy firms in the law firm playbook, and for money-heavy ops teams in the upcoming financial services playbook: find the retyping, make it visible, automate the worst of it.

The clipboard never fully disappears, by the way. It just stops being the system of record and goes back to being a clipboard. Dave's fine with that. Ask him on a humid day.