Use Cases  /  Manufacturing / Ops
Manufacturing / Ops

We built one screen to run production, instead of juggling three apps

Processing a job used to mean one person juggling the ERP, the CRM, and paper across a dozen windows. We built one app the whole shop logs into, where each role sees only the decisions they own - and a job goes to the floor in one checked, safe click. Not a replacement ERP, a purpose-built front-end on it.

One job meant juggling the ERP, the CRM, and paper

To push one order to the production floor, someone on our team had to stitch it together across three systems - the ERP on one screen, the CRM on another, and paper in between - re-keying as they went, and just hoping the signed contract matched what the ERP would actually build. It was slow, it was error-prone, and it was the kind of work only the person who had always done it really understood.

The generic ERP screen shows everyone everything

Part of the problem is that an off-the-shelf ERP screen shows everyone the same everything. The person releasing a job, the person shipping it, and the person buying parts all stare at the same dense screen full of fields that aren't theirs. Nobody's view matches the job actually in front of them, so everyone wastes time hunting for the five things they care about.

One app, and each person sees only their decisions

So we built one app the whole shop logs into, and gave each role its own view of the same shared records. The foreman sees the jobs waiting to be released, the shipping clerk sees what is ready to go, the buyer sees what to order - each screen filtered to the decisions that person actually owns. Under the hood it is one connected surface over about ten workstreams, from production to planning to shipping to receiving, but no one has to see the whole thing to do their part.

One record · Order A-1042ForemanReady to releaseShip date setParts reservedonly their decisionsShipping clerkBuiltReady to shipTracking addedonly their decisionsBuyer2 parts shortOn orderReceivedonly their decisions

Everyone logs into the same app, but each person only sees the decisions they actually own.

A job goes to the floor in one checked click

The headline feature is releasing a job to production. What used to be a careful multi-window ritual is now one button - but a safe one. Behind that click runs an ordered, resumable sequence that converts the order, recalculates it, sets the dates, reserves the parts, carries the notes, prints the cut sheet, and only then, at the very end, sends the customer their confirmation. If any step fails, it stops and picks up where it left off rather than firing a half-finished release. One click for the person, a dozen careful steps underneath.

One click →ConvertRecalcSet datesReserve partsCarry notesCut sheetCustomeremailLASTa failed step halts and resumes, never a half-finished release

We tested it like the shop's livelihood depended on it

Because it does. Before we trusted this with real orders, we ran an autonomous end-to-end test campaign - disposable orders pushed all the way through production and torn back down to zero residue, each one checked a dozen ways. We proved the build math against the real configurator across 6,327 actual positions, and the testing caught a quiet bug that would otherwise have printed an out-of-date cut sheet to the floor. The Ironwood cut sheet is now the shop's real cut sheet - the old ERP print is just a fallback.

One app · one loginQueueReviewPlanningCut sheetFulfillmentPurchasingReceivingInventoryRMASystem of recordlivedesigned

Don't hide the bad data - fix the system of record

The most important lesson came from a mistake we almost made. Some parts orders showed up wrong in the app because they came in through a side door instead of the main workflow. The tempting fix was to just hide the bad rows so the screen looked clean. We didn't. The real fix was to correct the system of record so the app faithfully reflected reality - because the moment your app keeps its own private version of the truth, you have built a second system that will fight the first one forever.

The temptation was to hide the incorrect rows in the app. The real fix was to correct the system of record, so the app faithfully reflects reality. You never want your app to become its own competing source of truth.

Build the front-end, let the system of record stay the truth

That is the whole philosophy in a sentence: build the front-end your team actually needs, and let the system of record stay the source of truth. Our ERP is still the system of record - we did not replace it. We built a purpose-built surface on top of it that speaks each person's language and writes every change back where it belongs. For an owner, that is the sweet spot: your people get software shaped around how they really work, and your data stays in one place you can trust.

It is not a replacement ERP. It is a purpose-built front-end on the one we already have.

Built on:One connected surfacePer-role filtered viewsOne-click release sagaWrites back to the system of recordAutonomous test campaignEngine-true build math

This is the app our shop floor runs on

No demo - the whole production team releases, ships, and receives real orders through this every day. If your team is juggling an ERP, a CRM, and paper to do one job, tell us about your setup and we'll tell you honestly whether a surface like this makes sense for you.

Talk about your setup