Every hardware company that outgrows spreadsheets and travelers reaches the same fork. Hire a software team and build an MES in house, or buy one from a vendor. Both paths work for some companies. Both have costs that don't show up until a year or two in.
We should say up front where we stand. Factorial is a new company, and we don't have a long list of customers to point to yet. But it isn't our first MES. Between us, we've spent roughly eight years building MES software and about twelve building software in general, and we've seen up close where both paths tend to go wrong. This post is our honest read of the trade-offs.
Building in house
Building usually means hiring somewhere between three and ten software engineers. Most of them will never have built an MES. Many will never have used one.
There are real advantages:
- The feedback loop is tight. The people writing the software sit next to the people using it. A problem on the floor in the morning can be fixed by the afternoon.
- Anything can be integrated. That unusual test rig nobody sells a connector for? Your team can wire it up on the spot.
And real costs:
- The hard problems are still hard. Revision control on in-flight work, inventory that splits and merges, traceability through many levels of assembly, many people editing the same records at once. A new team will meet the same problems we've already worked through, and solve them for the first time on your production floor.
- It's not a line item, it's a department. The cost isn't a vendor invoice. It's several full software salaries, every year, for as long as the system exists.
- The outcome is uncertain. A few companies have built excellent internal manufacturing software. They had the years, the headcount, and the software culture to do it. Most hardware companies are not software companies, and even teams that write excellent machine-level code find that application software brings a different set of challenges.
Buying an established MES
Established vendors have earned their position, and there's a lot to like:
- Support. We generally hear good things about support channels, though it varies by company.
- Experience across customers. A vendor sees how many factories work. At its best, its software carries that experience and keeps you on a well-trodden path, so you can focus on building your product.
- Scale. With aggregated, anonymized data from many customers, a vendor is in a position to develop genuinely better planning and quality tools than any single factory could.
The costs are different, but they're real too:
- Price. Economies of scale should make buying cheaper than building. In practice, there hasn't been much competition in this market, and MES contracts are still expensive.
- Foundations that predate AI. Most established systems were designed long before coding agents existed, and it shows in how hard they are to extend and integrate.
- Hard to self-host, if you can at all. Modern software is often built as many small services, each with its own place to store state. Asking a customer to run that is asking them to operate a lot of infrastructure, and to keep every piece patched against security vulnerabilities.
- API contracts that can't change. The longer a vendor has been around, the more it is bound to decisions made decades ago. An endpoint designed twenty years ago becomes critical to one large customer, and every new feature has to work around it.
The customization problem
Every factory eventually needs something its MES doesn't do. With most established systems, that need lands in one of three places.
It's customizable, and it's on you. The vendor provides a scripting editor or a drag-and-drop builder, but few guardrails. Documentation is often thin, so it's hard to learn what the system can do or which methods you can call. Like most engineers, we've had to build a lot of tools in editors like these. For anything more than a few lines, you want a repository, a history of changes, tests, and code someone else can maintain later. Without them, these customizations become the weak point. Somewhere in many organizations, a small HTML form that one person built years ago is quietly holding the whole operation together, and nobody knows it until it breaks.
It's not customizable, so you wait. The vendor agrees to build it, and it goes on the roadmap. Sometimes it doesn't arrive, and often for good reasons: a change that helps you has to be safe for every other customer, including the one whose BOMs are fifteen levels deep with a thousand components at each level. You can end up paying for priority just to get your request considered.
It's somewhere in between. There are customization tools, but they only handle simple cases. You're left choosing between forcing a slow, untestable workaround to fit and waiting, or paying, for the real thing.
What we're trying to do differently
We started Factorial because we think a manufacturer shouldn't have to choose between software that fits and software that works. Here's what that means in practice.
We've built this before
Factorial is the MES we wanted to build after years of building others. We've seen which early decisions an MES ends up living with for a decade: how revisions attach to work already on the floor, how inventory history is stored, which API shapes become impossible to change. We've seen the wrong answers up close. Factorial starts from what we learned, so you get those lessons without paying for them on your floor.
We designed the data model and API before we built them
We're both backend engineers who care a great deal about data. We spent a long time on the shape of the data model and the API before writing the features on top of them, precisely so we don't end up bound to contracts we regret. Analytics, for example, is served from a set of stable views, so internal schema changes don't break the queries customers depend on.
It's easy to self-host
A self-hosted deployment is a single application binary, a PostgreSQL database, and file storage. That's it. It runs on a server in the factory or on a cloud server you control, and a small team can manage it.
Features that are hard to find elsewhere
- Live data by default. Screens update as work happens, without a refresh. We wrote about why that matters separately.
- History you can actually work with. Events and activity feeds record who did what, and how, and can be filtered by person or time when you're investigating.
- Traceability that tells the truth. Factorial records every installation, consumption, split, and merge, and when the physical process made something uncertain, it says so rather than guessing. When a supplier reports a bad lot, every unit that could have used it is on the list.
Extensibility built by developers, for developers, operators, and their agents
Customization in Factorial is code, with the things code should come with: versions, approvals, tests, logs, and permissions. That doesn't mean only software engineers can do it.
Factorial is built so a coding agent can do the heavy lifting. The CLI tells it what it can do, the docs tell it how Factorial behaves, and every script can be run against a mocked payload that lists its side effects instead of applying them. So the agent doesn't just write the code. It checks that the code does what was asked before anyone turns it on.
In practice, that means you don't need a dedicated software team to extend your MES. Any engineer on your software team can pick up a request in an afternoon. A manufacturing engineer or a technician who knows exactly what the line needs can often describe it in a prompt and get back a plugin that has already been tested, or a custom screen to try. Approvals and permissions decide what gets enabled, so the ease never comes at the cost of control.
What's available:
- Plugins are written in a familiar subset of Python. Hooks, receivers, jobs, slash-command actions, and inventory constraints cover reacting to changes, accepting webhooks, running on a schedule, automating routine work, and enforcing material rules. Each can be tested against a mocked payload before it's enabled.
- The fctl CLI gives people and coding agents the same discoverable interface, with the same permissions.
- Pages are custom screens, such as a station display or a dashboard. Ask an agent for the screen you need. It calls Factorial's API as whoever is viewing it, so there are no API keys to manage.
- A complete REST API and read-only SQL analytics for the questions no screen anticipated.
We go deeper on this in An MES your coding agents can program.
Built to be fast and tested hard
Factorial is written in Go on PostgreSQL, and we target p95 response times of 100 milliseconds at operational scale. It's performance-tested with tens of millions of inventory items and tasks. Our tests combine workflow simulation with property-based testing of core manufacturing rules, exercising unexpected sequences of operations to check that inventory, traceability, permissions, and revision history stay correct.
A small team that works with you
We intend to keep the team small: builders who also talk to customers, with no layers in between. Low overhead means we can be sustainable on a small number of customers, and that our priority stays where it belongs, on making manufacturing easier, more reliable, and more efficient. We'd like to be in your factory, working through your processes with you.
The honest trade-off
Choosing Factorial today means choosing a newer company. We test and simulate as much as we can before anything reaches a customer, but we don't yet have years of production history to show you. The other side of that is attention: as an early customer, you work directly with the people who built the system, and your feedback shapes what comes next.
Building gives you control and a tight feedback loop at the cost of a software department. Buying gives you experience and support at the cost of flexibility. We think you shouldn't have to give up either.
Start with Why Factorial, or tell us about your operation and we'll give you an honest read on whether we're a fit.