Over the past months, several customers have asked us the same question: instead of paying licence fees for a commercial EA platform, could we use AI to build our own? It is a compelling idea, especially for smaller organisations. We have not built our own EA platform, but we have built our own business application with AI agents, and that experience gives us a practical view of what such a decision really involves.
Why this question comes up now
AI coding assistants have fundamentally changed the cost-benefit analysis for in-house development. Work that once required a development team and a substantial budget can now be tackled by one person with domain knowledge, patience and a capable coding agent. At the same time, commercial EA platforms are designed for enterprise requirements such as fine-grained permissions, certified integrations, audit trails and hundreds of users. Smaller organisations pay for that scope whether they need it or not.
From that perspective, building a small application inventory or a lightweight EA repository no longer seems unrealistic. A useful first version can be created surprisingly quickly. The harder question is what happens when the tool becomes important, expectations grow and it has to remain reliable.
What building our own tool taught us
Since February, AI agents have written every line of ITM InMind, our internal platform for customer management, asset management and our SAP LeanIX tooling. It is in production and used across our company every day. The first modules confirmed the promise: a focused application with a limited scope was simple and fast to build. The challenge emerged later, when the first prototype turned into an application that is used and trusted in our daily business. Compliance requirements meant role-based access control, audit logs, controlled releases and backups. Once every new feature had to respect all of that, our coding agents needed twice, sometimes nearly three times, as long per feature. Before review, roughly every third commit contained a logic error.
We have written up that journey in detail, including why what actually works is better called AI-assisted development than vibe coding, in Vibe-coding our own business application. The short version: building a focused tool is genuinely fast. Keeping it reliable once people depend on it is the actual work.
Count your use cases first
Our honest answer to the EA tool question depends on who is asking and on how thoroughly the required scope has been considered.
Start with the full list of your use cases. A genuine EA platform may need configurable data models, calculated fields, workflows, data-entry wizards, surveys, notifications and diagramming. Each capability is a sizeable project in its own right. More importantly, the difficult questions arise where they interact: What happens when a survey contains a conditional field whose condition depends on a calculated field? When is that calculation refreshed? Which workflow runs after submission, who may see the result, and how are changes represented in the audit trail? Commercial platforms have spent years resolving such edge cases.
Then consider the day-to-day mechanics. In a commercial platform, an administrator adds a field to the data model through configuration. In a self-built tool, every new field might require a database migration, changes to backend models and the user interface, permission checks, tests and a deployment. If fields must be configurable, calculated or conditional, the system also needs validation rules, dependency handling, versioning and predictable behaviour across forms, surveys, imports, workflows, APIs, notifications, audit logs and backups. Complexity multiplies rather than merely adding up.
The real question is not whether you can build it. It is whether you want to operate and maintain it for years.
With enough time and token budget, all of these features can be implemented. That is not the decisive question. The real question is whether you want to operate and maintain them for years. At some point, the organisation may spend more time building, testing and maintaining its platform than working on the architecture topics the platform was meant to support.
Our answer
In our view, building your own EA tool is most interesting if you have never had one before and if you are not a global organisation with multiple groups and teams that would work in it. In that setting the scope stays small, the licence savings are real, and losing enterprise features you would never have used is no loss at all.
If you operate in an enterprise environment, we would not replace the commercial platform. Configurable permission models, certified integrations, auditability, performance at scale and support contracts are precisely where these products earn their licence fees. The effort required to reproduce and maintain these capabilities is regularly underestimated.
For many organisations the practical answer lies in between: keep the commercial platform as the system of record and build custom tooling around it. That is what we do ourselves. The SAP LeanIX tooling inside InMind does not replace the platform. It extends it.
If you are weighing this decision for your own organisation, we are happy to share our experience in more detail, including the parts that did not go smoothly. Talk to us.