Over the past few months, several customers have asked us the same question: instead of paying license fees for a commercial EA platform, could we use AI to build our own? It’s a compelling idea, especially for smaller organizations. We haven’t built our own EA platform, but we have built our own business application using AI agents, and that experience gives us a practical understanding of what such a decision really entails.
Why is this question coming 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 handled by a single person with domain expertise, patience, and a capable coding agent. At the same time, commercial EA platforms are designed to meet enterprise requirements such as fine-grained permissions, certified integrations, audit trails, and support for hundreds of users. Smaller organizations 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 initial version can be created surprisingly quickly. The more difficult question is what happens when the tool becomes important, expectations rise, and it must remain reliable.
What Building Our Own Tool Taught Us
Since February, AI agents have written every line of code for ITM InMind, our internal platform for customer management, asset management, and our SAP LeanIX tools. It is in production and used throughout our company every day. The first modules lived up to expectations: a focused application with a limited scope was simple and quick to build. The challenge arose later, when the initial prototype evolved into an application that is now used and trusted in our daily business operations. Compliance requirements mandated role-based access control, audit logs, controlled releases, and backups. Once every new feature had to meet all of these requirements, our coding agents needed twice—and sometimes nearly three times—as long to develop each feature. Before review, roughly one in three commits contained a logic error.
We've documented that journey in detail—including why what actually works is better described as AI-assisted development rather than "vibe coding"—in our post, "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 real work.
Count your use cases first
Our honest answer to the question about the EA tool depends on who is asking and on how thoroughly the required scope has been considered.
Start with the complete list of your use cases. A true EA platform may require configurable data models, calculated fields, workflows, data-entry wizards, surveys, notifications, and diagramming. Each of these capabilities is a significant project in its own right. More importantly, the difficult questions arise where these features 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 can view the result, and how are changes recorded in the audit trail? Commercial platforms have spent years resolving such edge cases.
Then consider the day-to-day mechanics. On a commercial platform, an administrator adds a field to the data model through configuration. In a custom-built tool, every new field might require a database migration, changes to backend models and the user interface, permission checks, testing, and deployment. If fields must be configurable, calculated, or conditional, the system also needs validation rules, dependency handling, versioning, and predictable behavior across forms, surveys, imports, workflows, APIs, notifications, audit logs, and backups. Complexity multiplies rather than simply adding up.
The real question isn't whether you can build it. It's whether you want to operate and maintain it for years.
With enough time and a sufficient budget, all of these features can be implemented. That is not the key issue. The real question is whether you want to operate and maintain them for years to come. At some point, the organization may end up spending more time building, testing, and maintaining its platform than working on the architectural issues the platform was intended to support.
Our answer
In our view, building your own EA tool is most appealing if you have never had one before and if you are not a global organization with multiple groups and teams that would use it. In that scenario, the scope remains small, the savings on licensing are significant, and forgoing 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 what make these products worth their license fees. The effort required to replicate and maintain these capabilities is often underestimated.
For many organizations, the practical solution lies somewhere in between: keep the commercial platform as the system of record and build custom tools around it. That is what we do ourselves. The SAP LeanIX tools within InMind do not replace the platform; they extend it.
If you're considering this decision for your own organization, we'd be happy to share our experience in more detail—including the parts that didn't go as planned. Get in touch with us.