Building your own MES vs buying one: an honest comparison
Building an MES in-house usually beats buying for the first six months and loses over three years, because the visible work of screens and workflows is a small fraction of the total. The cost sits in traceability, audit trails, scheduling, protocol connectivity, and a maintenance burden that never ends.
Why building always looks reasonable at the start
The argument for building is genuinely appealing, and usually made in good faith.
You know your processes better than any vendor. You have developers, or can hire them.
Commercial MES licensing looks expensive against a couple of engineer-years.
And every vendor demo shows something that does not quite match how your plant actually works.
The first phase usually confirms all of this.
Within a few months there is a working system. Production orders, an operator screen, a dashboard.
It fits the process exactly, because it was built for it. The decision looks vindicated.
The difficulty is that the visible part of an MES is the small part.
Screens and workflows are perhaps a fifth of what a mature system does.
The rest surfaces gradually, and most of it surfaces after the initial team has moved on.
What surfaces later
| Requirement | Why it is harder than it looks |
|---|---|
| Genealogy | Tracing both directions through splits, merges, rework and partial consumption is a hard data modelling problem, and getting it wrong is discovered during a recall |
| Finite capacity scheduling | Real scheduling with changeover, dependencies and calendars is a constraint-solving problem, not a sort |
| Audit trail | Not a log table. Append-only, undisableable, covering before and after values, surviving migration |
| Protocol connectivity | OPC UA is a substantial specification. Reconnection, quality flags and stale-value detection are where the effort actually goes |
| Concurrency | Two operators consuming the same lot at once, on an unreliable shop-floor network, with partial writes |
| Retention | Records readable for years, across schema changes and system upgrades |
| Offline behaviour | What a floor terminal does when the network drops, and how it reconciles afterwards |
None of these are exotic. They are all normal MES requirements.
What they share is that none appear in the first phase, and each is individually the size of a small project.
The cost that is easy to miss
The comparison usually made is developer cost against licence cost.
That comparison is not wrong. It is incomplete in three ways.
Maintenance never ends.
A production system needs ongoing work. Dependency updates, bug fixes, changes as processes evolve.
A common planning figure is 15 to 25% of build cost per year, indefinitely.
Over three years that alone can approach the original build.
Opportunity cost is real.
The team building the MES is not building something else.
For a manufacturer, MES is rarely the software that differentiates the business. It is infrastructure that enables it.
Continuity is a genuine risk.
In-house systems concentrate knowledge in few people.
When they leave, the cost is not just replacement. It is the period where nobody fully understands why a rule exists.
This is the risk that most often converts a built system into a bought one, usually under time pressure.
Set against a bought system, the comparison needs licence, implementation, support and internal admin time on the other side.
Plus the same change costs after go-live covered in the MES selection guide.
Neither side is free.
When building genuinely wins
Building is the right call more often than vendors admit.
The conditions are specific.
- Your process is genuinely unusual and that is your advantage. Not “our process has quirks”, since every plant believes that. Genuinely unlike what the market serves, in a way that matters commercially.
- Scope stays deliberately narrow. One well-defined problem, solved well, integrated with bought systems for everything else. This is the strongest case by a wide margin.
- You have a permanent software team. Not a project team. People who will still be there in year four.
- Regulatory burden is light. If 21 CFR Part 11 or CPOB apply, the validation and audit trail work is substantial and unforgiving. It is not where a first-time team should be learning.
The pattern that works most reliably is hybrid.
Buy the platform for the parts that are the same everywhere. Execution, traceability, scheduling, connectivity.
Then build the thin layer that is specific to you on top of it.
This depends on the bought system being extensible, which is worth testing during evaluation rather than assuming.
A comparison worth doing
If you are weighing this, the exercise that clarifies fastest is not a feature matrix.
It is this:
- Write down the twenty requirements you know about. Include traceability, audit, scheduling, and connectivity explicitly.
- Estimate each one honestly, as though quoting for a customer.
- Add 40% for the requirements you have not thought of yet. This is not padding. It is the historical pattern.
- Add three years of maintenance at 20% of build per year.
- Compare against licence plus implementation plus support over the same three years.
- Ask separately: what happens if the two people who built this leave?
Step six changes more decisions than the arithmetic does.
Where VECHR MES fits
VECHR MES exists because of the failure mode on the other side of this decision.
It was built after repeatedly seeing plants where commercial MES software was too rigid, every customisation became a fight against the platform, and building in-house started to look like the only option.
So the platform is designed to be configured by the plant rather than by its vendor.
Specifications, routing and quality rules are changed through a visual designer. The Process Orchestrator provides low-code automation with 50+ node types and a TypeScript plugin SDK for genuinely specific logic.
That is aimed squarely at the hybrid pattern. Buy the hard parts, build the thin specific layer.
The hard parts are the ones worth not rebuilding. Two-way genealogy across splits and merges, finite capacity scheduling with tanks and pumps as first-class constraints, hash-chained audit trails that cannot be disabled, and native OPC UA, MQTT and Modbus TCP connectivity.
Each is a project in its own right. None of them differentiate your product.
Frequently Asked Questions
Is it ever right to build an MES in-house?
Yes, in narrow cases. If your production process is genuinely unlike anything on the market and that difference is your competitive advantage, if you have a permanent software team rather than a project team, and if the scope stays deliberately small, building can work. The failure mode is building something general-purpose that turns out to be a worse version of a product you could have bought.
What about building on a low-code platform?
It shortens the first phase meaningfully, since forms, workflows and dashboards come quickly. What it does not shorten is the hard part. Finite capacity scheduling, genealogy across splits and merges, tamper-evident audit trails, and industrial protocol connectivity all need real engineering regardless of the platform underneath.
How do we compare cost honestly?
Compare three years, not the first project. Include the loaded cost of developer time, not just salary. Include the cost of the team being unavailable for other work, ongoing maintenance at a realistic percentage of build cost per year, and the cost of continuity when the person who wrote it leaves. Set against licence plus implementation plus support, the picture usually changes.
What is the most underestimated part of building?
Traceability. Recording what happened is straightforward. Reconstructing genealogy in both directions across splits, merges, rework loops and partial consumption is a genuinely hard data modelling problem. It is also the one discovered late, usually during the first recall or audit, when it matters most.
Can we start by building and buy later?
It is possible but rarely cheap. The migration cost is dominated by historical data. Production history, genealogy and audit records have to move in a form that stays valid for retention and audit purposes. It is much easier to pilot a bought system on one line than to unwind a built one across a plant.