The Shape We Wouldn't Force
A predefined model for every record ships fast. We refused it anyway.
June 9, 2026
A predefined model ships fast.
You decide the fields in advance. A pump has these attributes, a valve has those, a bearing has these others. You write the structure down, lock it in, and build the platform to fill it. It demos well. It is easy to explain. And for a single, well-understood category of data, it works.
We refused to build Ark that way — and paid for it in the slowest, least visible part of the journey: the beginning.
We built Ark so the master describes itself. The structure is driven by what the data actually is, not by a shape we decided in advance and forced every record to fit. That decision cost us speed when we had none to spare. It is also the reason Ark does what a predefined platform cannot.
Why the fixed shape is so tempting
Almost everyone who builds in this space starts with a fixed model, for a good reason: it is the path of least resistance, and early on it looks identical to the harder path.
You sit down with a category of MRO data — say, rotating equipment — and you enumerate it. Manufacturer, model, horsepower, RPM, mounting. You define those fields, build the forms, build the validation, and you have a working system in weeks. It governs rotating equipment well. The demo is clean. The customer sees their data, neatly structured, and they are satisfied.
The trouble arrives with the second category. Instrumentation does not look like rotating equipment. Electrical does not look like either. Fasteners, lubricants, safety equipment, spares for a specific OEM line — each has its own logic, its own attributes, its own definition of what a complete record even means. A fixed model meets every new category with the same answer: re-engineer. New fields, new forms, new validation, a new mini-build bolted onto the platform.
We have seen platforms accumulate dozens of these one-off extensions until the thing meant to standardize the data has itself become a patchwork no one can govern. The fixed shape did not save time. It deferred the cost and compounded it.
What it cost to refuse
Building a foundation where the master describes itself is harder at the start by a wide margin.
You are not enumerating fields. You are building the logic that lets the structure be defined by the data’s own definition — the dictionaries, the contracts that say what a given group and class of material requires, the engine that applies the right shape to the right record without a developer hand-coding each one. That is real engineering, and none of it demos in week three. While a fixed-model approach was already showing a customer their rotating equipment, neatly boxed, we were still building the thing underneath that would later govern rotating equipment, instrumentation, electrical, and everything after it without being rebuilt for each.
There were stretches where that gap was uncomfortable. The faster path was right there. Choosing it would have let us show more, sooner, in a sales conversation. We were building capability that would not pay off until the customer’s second and third and tenth category of data — and selling cycles do not always wait for the second category.
We ate that cost deliberately, because the fixed shape is a debt, not a saving. It is borrowed against every future category you do not yet know you will need. We did not want Ark’s customers discovering, two years in, that the platform governs the data they had at signing and re-engineers for the data they have since acquired.
Why the long horizon justified it
The case for the fixed model is a short-horizon case. Faster to a working demo. Cheaper to a first category. Easier to explain in a room. On a one-year view, it wins.
The case for a self-describing foundation only appears later, and it appears everywhere at once. It shows up the first time a customer adds a material type nobody scoped at the start, and the platform simply governs it. It shows up when the same Ark instance handles Item, Vendor, and Asset masters without three separate builds. It shows up when an organization’s catalog grows in a direction no one predicted — which every catalog does — and the foundation absorbs it instead of cracking.
That is the difference between a platform configured for the data a customer has today and one architected for the data they will have over the next twenty years. The first is faster to sell. The second is the only one still standing when the data changes.
Organizations rarely ask about this at the start. They ask about the category in front of them. They notice the difference later — when the platform that was supposed to standardize their data has not quietly become the next thing that needs standardizing.
The predefined model is faster. It is easier. For one well-understood category of data, it is entirely sufficient, and we would say so.
For a platform meant to govern every master an organization will ever create, we made the harder choice. We built Ark so the structure follows the data, not the other way around — and paid for it in the slow early months while the foundation took shape.
It cost us speed we could not spare at the time.
It is also why, when a customer brings Ark a kind of data no one anticipated, the answer is not we will re-engineer for that. The answer is that the platform was built to expect it.
We Build. We Stay.
About the Author
Raghu Vishwanath is Managing Partner at Bluemind Solutions, a product engineering firm specializing in MRO master data governance. He writes about software engineering, AI, and building platforms that last.