Build vs buy MES: what small and mid-sized plants actually need

“We need better production data and visibility into downtime.” When a plant says that, the conversation often turns to an MES. Sometimes that’s the right call. Below: what an MES covers, the five realistic options for a smaller plant, from off-the-shelf manufacturing software to a custom app, and a build vs buy MES decision table for your next planning meeting.

What an MES does, in plain terms

A manufacturing execution system (MES) records what happens on the plant floor while it happens: what’s running on each line, how much good product and scrap came off, when the line stopped and why, and which materials went into which lot. Supervisors and managers then work from that record instead of end-of-shift estimates.

The ISA-95 standard from the International Society of Automation gives a useful map. It places MES at Level 3, manufacturing operations management, between Level 4 business planning systems such as ERP and the PLCs and other control devices at Level 2 (ISA’s overview of ISA-95). Put simply, an MES sits between the office and the machines.

What a full MES product typically bundles

MES vs ERP for small manufacturers

The ERP runs the business side: orders, inventory, purchasing, bills of materials and costing. The MES tracks what actually happened on the line this shift. ERP data is typically organized by order and date; floor data has to be organized by line, by minute and by stop. That gap is why an ERP report can show that an order finished late without showing the three stops that made it late.

Do you need a full MES? Start with the data problem

Set the software category aside. Write down the question your production data can’t answer today, in your plant manager’s words, then look at what it takes to answer it.

If one or two rows describe your plant, you have a focused data problem, and a focused tool can solve it. If every row applies, across several sites, a full MES deserves a serious look.

Price the problem before you price the software

The downtime cost calculator prices an hour of unplanned downtime from your own output rate, margin, crew and scrap figures, with no industry benchmarks. A small number may mean a spreadsheet and a better reason-code list are enough for now. A large one justifies a proper system, whichever route you take.

Your options, from full MES to a custom app on your own database

A smaller plant has five realistic routes: a full MES, or one of four MES alternatives for small manufacturers. None is wrong in general, and each is wrong for some plants.

1. A full MES platform

Broad, configurable software that covers most of the functions in the table above. Implementation is a project in its own right: mapping your lines, products and rules into the product’s model, connecting equipment and training every shift. It pays off when you’ll use most of the modules and several sites need to run one standard way.

2. MES-lite or production monitoring software

Subscription products focused on a few jobs, such as OEE dashboards, machine monitoring, downtime capture or digital checklists. They start quickly and the vendor runs the hosting. Check how pricing grows with machines, users or sites, whether you can use your own reason-code structure, and whether you can export your full history if you leave.

3. Your ERP’s manufacturing module

Some ERP systems offer shop floor control or production reporting add-ons. You get one vendor and one database, and the work orders are already there. Check whether it records individual stops with causes and durations or only totals per order, and whether its screens work for an operator at the line rather than a planner at a desk.

4. A spreadsheet or no-code app

The fastest way to pilot a form and a reason-code list on one line. It strains once several people edit at the same time, or when you need permissions, change history and reports across lines. See signs you’ve outgrown spreadsheets and low-code vs custom software.

5. A custom app on your own SQL Server

Software built around your lines, products, reason codes and planned vs unplanned rules, with screens designed for the device at the line. Every entry lands in your SQL Server database, where Tableau or your other reporting can read it directly. The trade-off: someone has to build, host and maintain it, and your process has to be settled enough to build around.

When buying makes sense

Buying is often the right answer: configuring a good product beats paying to build a weaker copy of it. Lean toward buying when:

• You need most of the function table, not one or two rows of it.
• Several sites must run the same way, and a common product is how you’ll enforce it.
• The product already works the way your plant does. The demo handles your real cases without anyone saying “you’d just need to change your process.”
• You want machine signals from your equipment, and the vendor already supports your machines and controllers.
• Nobody would own a custom system. If no one will make decisions about codes, changes and priorities, a vendor-run product is safer.

Run the vendor demo on your real cases

Before signing, hand the vendor these five tasks and watch each one done live in the product:

1. A real shift’s stops, entered with your own reason codes.
2. An awkward case, such as a changeover that runs long: can your admin set whether the overrun counts as planned or unplanned? (See planned vs unplanned downtime.)
3. Operator entry on the actual device at the line, by someone wearing work gloves.
4. A change to the reason-code list, made by your admin without a support ticket.
5. A full export of the test data into a CSV or your own database.

One or two workarounds are normal. A workaround for something operators do every shift is a reason to price a custom build as well.

When a custom build makes sense

Custom fits when the need is focused and specific to how your plant runs. Lean toward building when:

• One or two data problems are clear, such as downtime or traceability, and the rest of a full MES would sit unused.
• “We need software that follows our specific process.” Your reason codes, planned vs unplanned rules or traceability steps don’t fit a product’s model without workarounds.
• The data has to land in your SQL Server, shaped for the reports you already run. Our downtime database schema guide shows what that structure looks like.
• Operators need fewer fields and their own terms on screens built for the line, not an office screen squeezed onto a tablet.
• Subscription costs would grow faster than the value as you add users, machines or sites.
• Floor data has to reach other systems, such as your ERP, through their APIs or database, so nobody retypes counts.

What a focused production app covers: one example

Chelten House Products is a fourth-generation food manufacturer of sauces, dressings and condiments. We built them a custom manufacturing data-management application where operators record production performance, product traceability and equipment downtime. It distinguishes planned from unplanned downtime, records causes and durations, and has administrative controls. The data is stored in SQL Server, where it supports Chelten House’s Tableau reporting. The Chelten House case study has the full scope.

When custom is the wrong answer

• Your process still changes every week. Pilot it on a spreadsheet or no-code app until the fields and codes settle, then build.
• You need nearly every row of the function table across several sites. That’s what full MES products are for.
• A product passed your demo honestly. If it handles your real cases, buy it.
• No one will own it. Custom software needs someone inside the plant to make decisions about it and a team to maintain it.

The hybrid: buy for the standard parts, build for your process

Often the strongest answer splits the job. Keep the standard parts in products that already do them well, build the piece that has to follow your process, and connect the two so nobody types the same number twice.

Common hybrid shapes

• ERP plus a floor app. The ERP keeps orders, inventory, bills of materials and costing. A custom app records runs, stops and lots at the line and sends completed quantities back to the ERP through its API. See how to eliminate double data entry.
• Machine monitoring plus operator reasons. A monitoring product captures run/stop status from the equipment. A custom screen at the line asks the operator why, using your reason codes, and attaches the answer to the stop.
• Several sources, one reporting database. Floor data, ERP extracts and quality results land in SQL Server reporting views, so Tableau reads one consistent set of tables.

Rules that keep a hybrid working

1. Pick one system of record for each piece of data: orders live in the ERP, stops live in the floor app.
2. Decide which way each field flows, and how often.
3. Log every sync, and alert a named person when one fails.
4. Give each connection an owner, like any other system (see API integration services).

Build vs buy MES: a decision table for small and mid-sized plants

Find the rows that describe your plant. If they point the same way, that’s your starting route. If they split, look hard at the hybrid.

Put numbers next to the table

Pair the downtime cost from earlier with the build vs buy software calculator, which compares subscription costs with a build quote over 1 to 10 years and shows the break-even month. Nothing you type is sent anywhere unless you choose to send it to us.

A practical first step, whichever way you lean

1. Write down the one question your production data can’t answer.
2. Agree on the fields and reason codes that would answer it. How to track production downtime lists the minimum fields for each stop, and downtime reason codes has a starter list.
3. Pilot on one line until every shift records stops the same way.
4. Then decide what to buy, build or connect, based on what the floor actually records.

For more on plant data and the software decisions around it, browse our guides.