A thirty-person technical office closes its fifth project in eighteen months on the same technical platform, which it prescribed on all five. The technical lead reviews the hour allocation, expecting the usual compression curve: the first project always takes longer, the fifth should take roughly half. The report contradicts the expectation. The first project took six weeks of platform configuration; the fifth took five and a half. The learning curve the office was carrying as an intangible asset does not appear anywhere. A quick look at the five project files reveals why: each project has been configured manually through the platform's administration interface. Entity types redefined one by one. Roles reconfigured one by one. Workflows reimplemented one by one. Custom fields recreated one by one. Nothing done on the previous project has been carried into the next, because there was no technical way to do so.
The compound advantage that should accumulate across a portfolio of similar projects does not materialize when configuration lives inside the platform rather than outside it. Anything that cannot be exported, versioned, tested and reapplied is what forces the technical office to redo the same work over and over, with no translation of senior experience into project acceleration. That phenomenon is not an engineering management problem: it is a technical property of the prescribed platform.
What the technical office is really paying for
The time cost of the blank start falls on the senior technical staff. They are the profile who understands the platform's architecture, weighs the implications of every configuration decision and guarantees that the workflow runs in production. They are also the most expensive and the most scarce profile in the office. Five projects times six weeks of configuration dominated by senior technical time equals thirty weeks of a resource that, had the platform supported exportable configuration, would have spent two or three weeks on the fifth project and the rest available for new work, proposals or internal methodology development. The loss does not appear in any file because it is not billed as loss: it is diluted across the technical hour line of each of the five projects, and it becomes visible only when someone looks at the aggregate.
The second effect is exclusivity. When a senior technician is configuring a project's start-up, they cannot be in another project's technical review or in the next proposal meeting. The technical office scales with senior profile or it does not scale; and with non-reusable per-project configuration, every new project hits the same bottleneck as the previous one.
Configuration as code: what changes when it exists
The technical answer is known in other domains — infrastructure, software deployment, data governance — under the name of configuration as code. Applied to a CMMS-plus-GIS platform, it means that the entire system configuration — entity types, attributes, roles, permissions, workflows, preventive-plan templates, criticality matrices, base cartographic layers — can be exported as a structured, human-readable file outside the platform, versioned in the office's usual source control, tested in a separate environment and reapplied to a new client through an API call.
When configuration lives outside the platform, every new client starts from a template that aggregates the knowledge accumulated across the previous projects. The senior technician reviews the template file, adapts it to the current client's specifics — two new asset types, one specific workflow, three different roles — tests it in the pilot environment and publishes it into production. Total configuration start-up time drops from six weeks of manual work to two weeks of directed work, and the team's seniority translates for the first time into measurable acceleration.
Three criteria to verify before prescribing
A technical office that wants to accumulate compound advantage across a portfolio of projects should verify three criteria during platform selection. The first is complete configuration exportability. It is not enough for the platform to allow the export of the asset master: entity types, workflows, roles, preventive-plan templates and every configurable structure must be exportable. Anything configured through the interface that does not appear in the export is something that will be reconfigured manually on the next project.
The second is reimport granularity. A good system allows importing only part of the file — workflows, without touching roles — and controlling what is overwritten and what is preserved. Without granularity, reuse turns into a total replacement that usually breaks the current client's specific configuration.
The third is template versioning. The technical office should be able to maintain an internal template repository with change history, comments and the ability to roll back to previous versions. Without version control, templates age without traceability and become the same problem they were solving.
The API as the decider of second-project margin
At Maptainer these three criteria are met by design: the platform's configuration is fully accessible through the OpenAPI 3.0 specification, import is granular by element type and configuration templates can be maintained in the source-control system the technical office already uses for the rest of its code and documentation. The practical consequence is that an engineering firm starting its third or fourth project on the same platform compresses configuration time measurably against the first, and that compression translates directly into project margin and into the office's capacity to take on more work with the same team.
What actually decides platform selection for an engineering firm
The classic conversation around technical platform selection revolves around feature list and license price. The conversation that actually decides three-year margin is different: which part of the configuration work can be packaged as a reusable template and which part stays outside that possibility. Platforms that give a clear and verifiable answer to that question are the ones that sustain the scaling of a small technical office. Platforms that retreat into the argument that per-project configuration is inevitable are, more often than not, the ones that turn the office's commercial gain into a slow accumulation of non-billable technical hours. The office that starts asking this question during evaluation reshapes its own margin structure before signing a single license, and the office that keeps evaluating by feature list ends up buying the constraint that will limit its growth for the following three fiscal years.