For decades the systems that ran production assumed processes were stable, product cycles were long, and change was the exception rather than the constant. That assumption no longer holds, and the rigidity that once looked like control now shows up as friction across every shift and every site. Three paths are open to manufacturers today: buy a traditional MES, build one in house, or build on a composable platform. They are not equally suited to what comes next.
What's inside the guide
- Traditional, homegrown and composable compared across seven dimensions that determine long-term value, not day-one feature checklists.
- What each one costs over three to five years, including the validation, infrastructure, and change-request line items most budget models leave out.
- Twelve questions to pressure-test any vendor including Tulip, with a scorecard you can take into demos.
- How manufacturers move without a big-bang replacement, and what the first year looks like.
How the three paths compare
Every vendor will say flexible. Most mean configurable, which is the ability to change values and toggle options inside a structure you cannot touch. The ceiling shows up in year two, when a process changes and the data model will not move with it. The guide compares traditional, homegrown and composable MES across seven dimensions: data architecture, time to value, ownership, workforce fit, connectivity, multi-site scale and validation.
Vendor evaluation scorecard
Those seven dimensions turn into twelve questions you can ask in a demo. Each one comes with the answer that should reassure you and the answer that should end the conversation. Run it on every vendor on your shortlist, including us.
| Ask the vendor | What a good answer sounds like | Disqualifying answer |
|---|---|---|
| 1. Outcomes: Show me customers accountable for the objectives we're accountable for. What did the system make measurably possible? | Named customers with comparable objectives and specific before and after | Generic feature demo, no comparable reference |
| 2. Data model: Can the data structure change after implementation, by our team, without you? | Yes, demonstrated live, including variation at order, unit, and batch level | “Submit a requirement and we'll scope it” |
| 3. Process change: Make a process change live, in the authoring environment, using someone who is not a developer | Done in the demo, by a non-developer, in minutes | Needs a developer or vendor resource. Configurable, not composable |
| 4. AI foundation: What does the data foundation look like, and does AI need a separate pipeline? | Contextualized data generated by normal operations, no retrofit | AI feature list with no answer on the data layer |
| 5. Connectivity: How does a new machine get connected, how long, and by whom? What about legacy equipment with no modern interface? | Configuration task, internal team, days | Professional services, custom code, or a vendor engagement |
| 6. Multi-site: How are standards enforced across sites? What happens when a local change conflicts with an enterprise standard? | Governed templates, approval workflow before production | Standardization depends on manual coordination |
| 7. Upgrades: How is a platform update applied to an existing deployment? | Applies cleanly, customer stays on the main branch | Vendor-managed backport per custom version |
| 8. Validation: What triggers revalidation? Is it scoped to the changed component or the whole system? What is generated automatically? | Component-scoped; platform validated on a published cadence | Full-system revalidation for any meaningful change |
| 9. Expansion: Name customers who went from one use case to multiple sites without re-platforming | Concrete and referenceable, existing artifacts extended | Hypothetical, or each expansion is a new project |
| 10. Team turnover: What happens to apps and automations when the person who built them leaves? | Documentation and version history captured by the platform, governance enforces standards independent of the author | “Our customers document as they go” |
| 11. Accountability: Who is liable when a self-service change causes a deviation or audit finding? | Named approval gates before production, a clear split between platform and solution accountability | Liability sits entirely with the customer, with no gate offered |
| 12. Relevant track record: Name the customer whose situation most resembles ours. What was hard about it? | A close analogue, named specifically, with the difficulties described honestly | A list of logos, or “we have hundreds of customers” |
What each path actually costs
License fees are rarely where the differences live. Integrator costs often run two to four times the license, and validation sits on top of that in regulated operations. Homegrown systems trade those costs for internal engineering hours, which feel cheaper because they are internal. Below the waterline sit the rest, including the one that never reaches an invoice: the process improvements stuck in a change queue, showing up later in yield, throughput and audit findings.
What AI needs underneath it
Most AI initiatives in manufacturing stall in the same place. The pilot works, and then it cannot move to a second line or a second site because the data underneath it was never structured for anything but the process it was built on. The operational data your system generates today is what any AI initiative will run on tomorrow. That is decided when you choose the architecture, not when you start the AI project.
What it looks like when it works
VEKA replaced a homegrown MES that had stopped keeping up. They started where the pain was most visible, setup and first-piece inspection, then added traceability and lot tracking, then moved from a static control plan to dynamic in-process inspection, then production tracking, maintenance, downtime, scrap and non-conformance.
Quality escapes fell from 530 a year to 66 across that period. Expansion to three more sites took weeks per site rather than a project each.
- ↓88% quality escapes
- ↓60% customer returns
- ↓50% first-piece inspection time
- ↓96% scrap from incorrect dies
We had piles of paper moving around the shop floor, and trying to trace back quality issues was like searching for a needle in a haystack.
Matt Ranallo, Director of Operational Excellence, VEKA
-
Configurability lets you adjust inside a fixed structure: change values, toggle options, select from predefined modules. Composability changes the structure itself. New data fields, workflows, integrations and logic are authored by the teams who own them. The practical test is who can make a change and how long it takes.
-
A traditional implementation runs 12 to 36 months to initial deployment, plus 6 to 12 months for validation in regulated operations. On a composable platform the first working version lands in roughly three months, and the system is refined continuously after that rather than delivered complete at go-live.
-
Beyond the license: integrator fees at two to four times the license, validation cycles on every meaningful change, per-site corrections, infrastructure and patching, and upgrade backports for customized sites. The guide breaks all of these out, along with re-platforming, which most budget models omit entirely.
-
When it is already installed and running, the processes it supports rarely change, and there is limited human interaction at the point of work. In that situation the cost of switching can outweigh the benefit, and the guide says so.
-
Yes, and that is the normal path. A composable layer runs alongside the existing MES, ERP and quality systems, taking on the workflows the incumbent handles poorly. As those gaps are filled, the case for the legacy system narrows and processes migrate gradually rather than in a cutover.
Twelve questions. Run them on us.
Bring the scorecard to a demo and ask us to make a process change live, in the authoring environment, with someone who is not a developer. We would rather be tested than trusted.