The composable MES pitch has fully arrived. Tulip has spent the past several years building out its app ecosystem and partner network around its low-code platform. Honeywell has been expanding Forge with prebuilt connectors and partner-built applications aimed at getting customers from pilot to production faster. And in 2026, Siemens and AVEVA have both been visibly growing their own partner marketplaces of prebuilt MES apps, connectors, and templates — the same basic move, dressed in each vendor’s own platform language. The framing is consistent across all of them: instead of a monolithic MES you configure once and live with for a decade, you assemble a system from a core platform plus a catalog of modular apps, many built by third parties, that you can install, swap, or retire as needs change.
That’s a real shift in architecture, and it’s not nothing. But for the plant IT team actually staring at a marketplace listing, the interesting question was never “whose app store is bigger.” It’s “what happens when I click install on an app built by a company I’ve never heard of, and it asks for a connection to my genealogy data, my OEE calculations, or my MES database.”
Why this is happening now
Marketplaces are a growth strategy as much as a technical one. A platform vendor that can point to a deep bench of partner apps and connectors has a stickier product and a lower cost of expansion — the vendor doesn’t have to build every quality-inspection template or SPC dashboard itself, it just has to build the platform and the App they run on, then let a partner ecosystem fill in the verticals. Low-code tooling makes this more plausible than it would have been a decade ago: apps can be built faster, by smaller partners, without deep MES engineering staff.
For manufacturers, the appeal is obvious. A prebuilt app for changeover tracking, andon escalation, or first-article inspection can shortcut months of internal development. The risk is just as obvious once you’ve been doing this long enough: every marketplace app is a new piece of software with its own release cycle, its own vendor relationship, and its own claim on your production data — installed, in many cases, by someone on the plant floor without a change-control ticket ever crossing plant IT’s desk.
The real procurement question: what does it touch, and who owns that?
Before an MES app marketplace listing gets anywhere near a production line, it deserves the same scrutiny you’d apply to any system integration — arguably more, because it’s easier to install than a traditional MES module and easier to overlook.
Data ownership and residency
- Does the app read your genealogy, OEE, or quality data, or does it also write back to it? Read-only apps are a fundamentally lower-risk category than anything that writes to production records.
- Where does data flow once it leaves your MES — does the app process it locally, or does it round-trip through a partner’s cloud tenant? If it’s the latter, you need a straight answer on data residency, retention, and who can access it, not a marketing page.
- If the app is retired or the partner relationship ends, what happens to historical data it generated or touched? Get this in writing before go-live, not after.
Versioning and platform coupling
A marketplace app is only as stable as its relationship with the underlying platform’s release cycle. When the core MES platform ships a version update — a new API version, a schema change, a UI framework bump — does the third-party app break, silently degrade, or get patched in lockstep? Ask the partner directly what their update SLA looks like relative to the platform vendor’s release cadence, and ask the platform vendor whether they certify or test marketplace apps against new releases before general availability. “Compatible with the platform” is a marketing claim; “tested against the current release by the platform vendor” is a due-diligence answer. Those are not the same thing, and marketplaces don’t always make the difference obvious.
API contracts, not API existence
Almost every app in these marketplaces will tell you it integrates via API. That’s table stakes. What matters is whether the API contract is documented, versioned, and stable — whether the partner commits to backward compatibility windows and deprecation notice, or whether they reserve the right to change endpoints without much warning. If you’re connecting into ISA-95-aligned data models or pushing data over OPC UA or MQTT Sparkplug B into the app, ask specifically how schema changes on either side get communicated and tested before they hit production.
Patch and support ownership
This is the question that gets skipped most often: when something breaks, whose ticket is it? A three-way relationship between you, the platform vendor, and the app partner needs a clear answer before install, not after an outage. Some marketplaces have formal certification programs with defined support tiers; others are closer to an open listing service where the platform vendor explicitly disclaims responsibility for partner app behavior. Read the marketplace terms, not just the app description — that distinction is usually spelled out in the fine print, and it should change how much production dependency you’re willing to put on that app.
Security posture
Any app touching plant floor systems inherits your obligations under frameworks like IEC 62443, whether the marketplace listing mentions that or not. Ask about authentication methods, whether the app requires broad service-account access or scoped permissions, and whether the partner has any independent security assessment behind it. A low-code app built quickly by a small partner is not automatically insecure — but “built quickly by a small partner” is exactly the profile that skips hardening if nobody asks.
The shadow-MES risk is real, and it’s organizational, not just technical
The fastest way to end up with unsupported shadow-MES sprawl is to let marketplace convenience bypass your existing change-management process. A low-code app that a line supervisor installs in an afternoon to solve a real, immediate problem can become permanent infrastructure nobody in IT knows exists — until it breaks during a platform upgrade, or an auditor asks who has write access to genealogy records and the honest answer is “we’re not entirely sure.”
The fix isn’t to ban marketplace apps. It’s to treat the marketplace itself as a procurement channel that needs a gate, the same way you’d gate a new supplier’s EDI connection or a new SCADA driver. That means a short internal checklist — data touch, versioning commitment, support ownership, security posture — that any app has to clear before it goes anywhere near a production system of record, plus an internal register of what’s actually installed and who approved it. Marketplaces make discovery and installation frictionless. Governance has to catch up to that, deliberately, because the platforms themselves aren’t going to slow down to make you comfortable.
What to watch
Expect platform vendors to differentiate increasingly on marketplace governance rather than just catalog size — certification tiers, security attestations, and formal compatibility testing programs are the features that will actually matter to plant IT teams a year or two from now, more than raw app counts. Whether Tulip, Honeywell, Siemens, or AVEVA get there first is a genuinely open question. It’s worth asking each of them directly, in the next MES RFP, what their certification and support model actually guarantees — because right now, the marketplace listing page usually won’t tell you.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
