> For the complete documentation index, see [llms.txt](https://engineering.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engineering.umh.app/company/why-we-exist.md). # Why we exist **Vision.** Data becomes what electricity already is: infrastructure every factory is built on. **Mission.** Build experiences that cut manufacturers' time to value. For us, that means a factory can build a new application in hours. ## How production works **Look around you. Everything you see was produced somehow.** All of it is made by physical equipment that needs electricity and compressed air to move mechanical parts. The equipment runs its own control logic under its own safety standards. Because the machines also talk to each other, together they form a complex distributed system. ### The Automation Pyramid **The Automation Pyramid stacks a factory's equipment in layers.** Every layer is a control loop wrapped around the one beneath. Take a buyer who orders 3,000 bolts for Friday. * The order lands in the ERP (enterprise resource planning). The ERP writes the invoices and manages the warehouse. * The ERP hands it down to the MES (manufacturing execution system). The MES does the detailed scheduling, for example line three, 500 per shift. * Below sits one SCADA (supervisory control and data acquisition) per line. It turns the schedule into a machine speed, 1,200 RPM. * At the bottom, the PLC (programmable logic controller) controls the physical components. Then everything runs in reverse. The PLC reports the actual speed and each layer reports upward. If line three has a mechanical failure, the MES may reschedule to another line. ### The OT ecosystem **The OT team keeps the equipment running with an ecosystem of its own.** The [OT team](/product/who-we-build-for/production-ot-team.md) runs the operational technology (OT). They replace electrical and mechanical parts and adjust the control logic. Most of them learned the job in a three-and-a-half-year apprenticeship that never mentions distributed systems. They can still keep such a system running because the OT ecosystem gives them everything they need. OT has its own computers, its own training and its own programming languages. You program a PLC the way you draw an electrical circuit diagram. Because it is safety-critical, the programmer does not get all the options. The ecosystem is so large that changing it is expensive. So it has stayed close to its 1990s design. A factory still builds a new line on these technologies because it is already in this ecosystem and its workforce knows it. Because the ecosystem is often outdated, companies want to build their own applications on top of it. ### Why factories connect their equipment **Factories connect their equipment so they can see data across lines from different vendors and build their own applications on it.** The equipment usually already tells you how much it produced and what state it is in. A factory usually wants to compare this across lines from different vendors. The equipment on each line cannot do that by itself. A plant that has to report emissions per tonne needs [energy monitoring](https://www.umh.app/solutions/energy-resource-management). A line that keeps stopping needs its [stop reasons captured](https://www.umh.app/solutions/oee). A team still retyping production numbers into SAP needs [that connection built](https://www.umh.app/solutions/erp-integration). More examples are on our [main website](https://www.umh.app). Who works in a manufacturing company and how they decide is in [Who we build for](/product/who-we-build-for.md#how-a-manufacturing-company-works). The long version is Jeremy's talk at [Local-First Conf](https://www.youtube.com/watch?v=bhcaFl69Dmc), in the first ten and a half minutes. ## Why it takes months today **Before anyone can build an application, someone has to reach each machine, get its data out and model it.** An enterprise has to do this for every machine in every plant. Reaching a single machine is already hard. Today you ask for the data in a meeting, or someone walks the shop floor with a USB stick. Over the network, you need a VPN on your laptop and a browser-based remote desktop. Because the networks are segregated, you then RDP into a jump host before you can SSH into the machine. Working like this is so frustrating that in practice someone gets on a plane to the plant. Getting the data out is harder than reaching the machine. You need to connect to over 50 different protocols. Next, the data has to be modelled so that it means the same thing across machines. Many companies pay a system integrator hundreds of thousands of euros to build a custom solution. Others try it themselves and get lost in the complexity. ## So we build UMH to cut that time **Because UMH already gets the data out of the machines and models it, building an app on it is fast.** Because of [opinionated simplicity](/product/product-standards/opinionated-simplicity.md), UMH also decides for the power user how to avoid the many small problems on the way. UMH has two products. [umh-core](https://docs.umh.app/) runs at the customer. It extracts the data from the machines and models it. The [Management Console](https://docs.umh.app/management-console) is the web interface where the [power user](/product/who-we-build-for/the-power-user.md) configures it. With UMH, nobody needs a VPN, a remote desktop or a jump host to reach the data. UMH never solves a business problem by itself. It shortens the path to one by making apps faster to build. The people using those apps might not use our product directly. So we have to [understand what our customers are trying to build](/product/who-we-build-for.md). The long version, in the founders' own words: [What We Do At UMH](https://www.umh.app/insight/what-we-do-at-umh). ## What we believe Own the outcome. Learn from mistakes. Focus on what moves the needle. ### Own the outcome You own the outcome, not the task. When we saw our customers struggling with UMH Classic, our earlier Kubernetes-based product, we didn't blame the market or our customers. We owned it, redesigned the architecture, and released UMH Core (umh-core). ### Learn from mistakes Your best idea might be wrong. We lost a large enterprise deal after three years. We were asking customers to understand Kubernetes and Kafka, complex infrastructure technologies that weren't making their work better, just more complicated. We adjusted. Now UMH Core is a single Docker container. We've let go of people who came from big companies where the goal was not doing anything wrong. You need to do things right, and for that you need to make mistakes. We hire for learning ability, not credentials. We need people who can learn fast, because we can't hand them patterns. They discover them with the team. ### Focus on what moves the needle If it doesn't move the needle, don't do it. What we say no to defines us more than what we say yes to. Every hour has to connect to business value. Indirect work counts. Developer experience, unblocking colleagues, team happiness. But you need to know how it leads there. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://engineering.umh.app/company/why-we-exist.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.