Industrial Engineer · Manufacturing Execution Systems

I build the software that runs the shop floor.

Seven years as an industrial engineer in manufacturing, now designing and delivering manufacturing execution systems end to end. Production tracking, downtime and scrap, OEE, plan versus actual, and the audit trail underneath all of it. Not websites. Not generic business apps.

7 yrs in manufacturing MS Engineering ManagementPython · Django · AI

Open to freelance, volunteer, and trial projects

Process MonitorLive
Raw SAP exportRECEIVED
Python pipelineRUNNING
Database → reportREADY
120 min4 minDaily report
cycle time
2 bottlenecks flagged for the morning meeting
7
Years in manufacturing
12+
Tools in production
120→4
Report cycle, minutes
Weeks
To deliver, not quarters

The boundary

Completely isolated from SAP. Here is exactly how.

Most descriptions of this work say "SAP integration" and quietly mean something riskier than it sounds. This is the whole mechanism, drawn out, so you can check the claim rather than take it.

Your side

Untouched SAP / ERP No connection. No credentials. No add-ons. No transactions driven. Nothing changed inside it.

Your team exports a report, exactly as they already do today

Air gap One file

What I build

  1. ParseRead the raw export as it comes out, headers and all
  2. ValidateReject anything that does not reconcile, loudly
  3. StoreA real database, so yesterday still exists tomorrow
  4. ReportThe exact layout your managers already expect

What this buys you: no IT project, no vendor sign-off, no security review of a new connection, and no way for this to break the system you cannot afford to break.

Measured, not estimated

What that actually saved

Before, by hand120 min
After, automated4 min

The bars are to scale. That figure is from a real build, not a projection, and your process may be better or worse. The honest way to find out is to send one real exported file and let me tell you what is possible with it.

How a project runs

Small first, and judged on its own

The risk in custom software is a long build that only reveals whether it was right at the end. This is structured so you find out early and cheaply.

Step 01

One conversation

About the process, not the software. Sometimes the right answer is that you do not need a system, and saying so costs you nothing.

Step 02

One real input

One exported file, or one paper form. The smallest real thing, so the estimate is grounded in your data rather than a discovery phase.

Step 03

One small build

A defined piece of work that solves one painful process and can be judged on its own. Paid or trial, your call.

Step 04

Extend, or stop

If it earned its place, the next module follows. If it did not, you stop having lost very little. That is the point of the order.

Straight answers

The questions worth asking me

These are the objections a careful buyer raises about a one-person practice. Better answered here than avoided.

What do you actually build?

Manufacturing software on Django and MySQL, automation of exported SAP reports in Python, Excel data pipelines, and AI agents on LLM APIs. Typical builds: role-gated factory systems for production and quality reporting, report suites that replace manual export-and-clean-up work, and agents that read production data and flag anomalies. If it removes manual work from a factory, it is in scope.

You are one person. What happens if you are not available?

It is a fair question, and you should not accept a system only one person can read. So the stack is deliberately boring: Django, MySQL, Python. Widely used, heavily documented, and maintainable by any competent developer without specialist training. Your operational data sits in a standard relational database on infrastructure you control, in a documented schema. The value is in that data and it does not depend on me continuing to be available.

Are you a software developer?

I am an industrial engineer who builds software, and I am specific about the difference. I am not a career senior developer. I know manufacturing processes, I know what the shop floor actually needs, and I build and ship working tools using AI assistance. More than 12 standalone tools are running in production. If you need deep computer-science engineering, hire a senior engineer. If you need someone who understands the process and can deliver working software against it, that is what I do.

You build with AI assistance. Does that make the result fragile?

AI is the implementation layer, not the judgment. Deciding what a plant needs, what the data model has to be, and what must never be allowed to happen is industrial engineering, and that part is mine. What AI changes is how fast a specified thing gets built and tested. That is why delivery is measured in weeks rather than quarters, and why one person can deliver what usually needs a vendor team. I state the method openly because you are entitled to know how the work is done.

Do you connect to our SAP system?

No, and deliberately not. I work from the reports your team already exports. There is no connection, no credentials issued to me, no add-on installed, and nothing changed inside SAP. That constraint is the feature: it removes the integration project, the security review and the risk to a system you cannot afford to have broken. One suite took daily reporting from roughly 2 hours of manual clean-up to under 4 minutes this way.

Tell me what the line cannot answer.

Start a conversation