Over the past few months, several customers have asked us the same question: Could we develop our own EA tool using AI, rather than paying licensing fees for a commercial platform? This idea is particularly appealing to smaller organizations. We haven’t built our own EA platform, but we have developed our own business application using AI agents, and this experience has given us a very practical understanding of what such a decision really entails.
Why this question is coming up right now
AI coding assistants have fundamentally changed the cost-benefit analysis for in-house development. Tasks that previously required a development team and a corresponding budget can now be handled by a single person with expertise, patience, and a powerful coding agent. Commercial EA platforms, on the other hand, are designed for enterprise requirements, such as fine-grained permissions, certified integrations, audit trails, and hundreds of users. Smaller organizations end up paying for this feature set even when they don’t actually need it.
A small, in-house application directory or a lean EA repository therefore seems entirely realistic. An initial, useful version can be created surprisingly quickly. Things become more challenging as soon as the tool gains importance, expectations rise, and reliable operation must be ensured.
What We've Learned from Our Own Development
Since February, AI agents have been writing every line of code for ITM InMind, our internal platform for customer management, asset management, and our internal SAP LeanIX tooling. InMind is now in production and is used daily throughout our company. The first modules lived up to their promise: a focused application with a limited scope could be implemented quickly and easily. The real challenge arose later, when what had started as a prototype became a central tool for our company. Compliance requirements meant role-based access control, audit logs, controlled releases, and backups. Since every new feature must now account for all of these, our coding agents take twice—and in some cases three times—as long to implement requirements. And the generated code must also be thoroughly reviewed, as roughly one in three commits contained a logic error.
We've described this process in detail—including why what really works should be called AI-powered development rather than "vibe coding"—in " Vibe Coding Our Own Business Application." The short version: Building a focused tool is actually quick. Keeping it reliable once people start relying on it is the real work.
First, list your use cases
Our honest answer to the EA tool question depends on who is asking and how thoroughly the required feature set has been considered.
Start with a complete list of your use cases. A true EA platform may require configurable data models, calculated fields, workflows, data entry wizards, surveys, notifications, and charts. Each of these features is a substantial project in its own right. The questions become even more complex when these features interact: What happens if a survey contains a conditional field whose condition depends on a calculated field? When is the calculation updated? Which workflow starts after submission, who is authorized to view the result, and how are changes recorded in the audit log? Commercial platforms have spent years resolving such edge cases.
Next, consider day-to-day operations. In a commercial platform, an administrator adds a data field through configuration. In a custom-developed tool, each new field may require a database migration, changes to backend models and the user interface, permission checks, testing, and deployment. If fields are to be configurable, calculated, or conditional, the system also requires validation rules, dependency handling, versioning, and predictable behavior in forms, surveys, imports, workflows, APIs, notifications, audit logs, and backups. The complexity doesn’t just add up—it multiplies.
The real question isn't whether you can build it, but whether you want to operate and maintain it for years to come.
With enough time and a sufficient token budget, all of these features can be implemented. However, that is not the key question. The key 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 on development, testing, and maintenance of its platform than on the architectural issues it originally intended to address with it.
Our Response
From our perspective, having your own EA tool is particularly appealing if you’ve never had one before and if you’re not a global organization where multiple groups and teams would be using it. In this context, the scope remains small, the savings on licensing are real, and doing without enterprise features you would never have used is no loss.
In an enterprise environment, we would not replace the commercial platform. Configurable authorization models, certified integrations, auditability, performance with large data volumes, and support contracts are precisely the areas where these products justify their license fees. The effort required to build these capabilities from scratch and maintain them over the long term is often underestimated.
For many organizations, the practical solution lies somewhere in between: keep the commercial platform as the system of record and develop the individual tools and integrations that are missing. That’s exactly what we do ourselves. The SAP LeanIX tooling in InMind does not replace SAP LeanIX; it extends it.
If you're considering this decision for your own organization, we'd be happy to share our experiences in detail—including the parts that didn't go smoothly. Please feel free to contact us.