AI can build your next homegrown system. Remember why you replaced the last one.

For anyone who remembers maintaining homegrown enterprise software, the promise of replacing commercial applications with AI-generated code may sound familiar.

Years ago, many organizations built their own systems because the available products could not meet their needs. Internal programming teams developed applications, connected them to other systems, and adapted them as the business changed.

Those teams often did impressive work. Their applications supported essential operations and reflected a deep understanding of the organization.

But keeping those systems running required a continuing investment in people, knowledge, maintenance, and infrastructure. Over time, many organizations decided that building and maintaining every major business application was becoming too expensive and difficult to sustain.

Today, AI is making custom software easier to create. Before organizations rush to replace their SaaS platforms, it is worth remembering what drove the move toward commercial software in the first place.

AI changes the effort required to produce code. The organization still inherits responsibility for the system that code becomes.

We have been through the build-versus-buy conversation before

In the homegrown model, organizations maintained programming teams responsible for everything from developing new features to fixing production failures.

As applications matured, those teams accumulated years of changes, exceptions, integrations, and business rules. Some were documented thoroughly. Others lived largely in the memories of the people who maintained them.

A seemingly small business request could require changes across several programs. Replacing a connected system could become a substantial development project. When an experienced programmer left, the organization could lose critical knowledge about how its operations actually worked.

Commercial off-the-shelf software, often called OTS or COTS, offered a different arrangement. Organizations could purchase an established product and share the cost of its continued development with other customers. Historical accounts collected by the Computer History Museum describe this shift in customer acceptance from internal development toward packaged software.

Some products were purchased through perpetual licenses with ongoing maintenance agreements. Others used subscription licensing. Increasingly, SaaS arrangements also placed responsibility for hosting and operating the application with the provider.

These models continue to coexist, and custom development still has an important place. But the economic appeal of commercial software was clear: organizations could meet common business needs without independently maintaining the entire underlying product.

AI makes the original decision look attractive again

Now an organization can describe an application and watch AI generate a working version.

The natural reaction is understandable: why continue paying a software subscription when we can build what we need ourselves?

SAP’s Philipp Herzig addressed this in a recent conversation with The Rundown AI. He challenged the idea that AI coding makes SaaS obsolete, pointing to the difference between generating an application and accepting responsibility for running it. An expense application still needs to handle permissions, reconciliation, changing requirements, and business rules across the countries where it operates.

That distinction belongs at the center of any proposal to replace enterprise software.

The first demonstration shows what AI helped create. It provides limited evidence of what the organization will spend supporting that application over the next five years.

A subscription may disappear from one budget while development, security, testing, infrastructure, and support obligations grow elsewhere.

Someone still has to understand what to ask for

AI can generate code from instructions. For enterprise systems, those instructions depend on a detailed understanding of the business and its technical environment.

An IT engineer needs to understand the requirements well enough to direct the work, recognize missing conditions, and evaluate whether the result behaves correctly.

That responsibility continues as the business changes.

A new organizational structure may affect approval authority. A policy change may alter access eligibility. An application update may change how an integration works. A security issue may require changes to software dependencies and another round of testing.

Each event requires someone to understand the existing system, provide appropriate context to the AI tool, assess the proposed changes, and confirm their effect across connected processes.

Prompting becomes part of the engineering work. It does not remove the need for architecture, documentation, testing, security review, or operational ownership. NIST’s software development reference model similarly calls for human validation of AI-generated content within established development and security processes.

AI may make engineers more productive. The staffing requirements may change substantially. Those improvements still need to be evaluated alongside the responsibilities that remain.

In IAM and IGA, the consequences reach across the business

This matters especially in Identity and Access Management (IAM) and Identity Governance and Administration (IGA), because identity systems determine whether people can do their jobs and whether access remains appropriate.

An AI-generated onboarding process might create an account successfully. A production identity system must also recognize an existing account, distinguish overlapping relationships, apply access policies, manage exceptions, and confirm what happened in each connected application.

Consider an employee who is also a student.

When employment ends, employee access should change while legitimate student access may need to continue. The system must understand which permissions belong to each relationship and apply the appropriate decisions.

As the organization introduces new applications and changes its policies, that logic must continue to work.

A mistake can leave a former employee with inappropriate access. It can also remove access from someone who still needs it, interrupting classes, payroll processing, customer service, or other essential work.

The business experiences the outcome regardless of whether a programmer or an AI tool produced the code.

The maintenance burden returns gradually

Homegrown systems rarely become difficult to maintain on their first day.

The burden develops through years of reasonable changes.

A department needs an exception. Another application requires a different integration. A temporary workaround remains in place. An urgent repair is completed before its documentation. The person who understood the original design moves on.

AI-generated systems can follow the same path. Faster development may also allow an organization to accumulate more applications and modifications than its staff can comfortably understand and support.

AI can help document, test, and maintain those systems. Organizations still need the discipline and resources to ensure that work happens.

The concern is the possibility of rebuilding a familiar operating model without accounting for its full cost: a growing collection of custom applications whose continued operation depends on internal expertise, ongoing changes, and sustained maintenance funding.

Evaluate the lifetime responsibility

A useful comparison between SaaS and an AI-generated replacement should include:

• Engineering effort for both initial development and continuing changes.
• Security maintenance, testing, monitoring, and recovery.
• Integration support as connected systems evolve.
• Documentation, staff transitions, and knowledge retention.
• Business disruption when processes fail.
• The eventual cost of replacing or retiring the custom system.

Commercial software also requires careful evaluation. Customers retain responsibilities for their policies, data, configuration, and use of the service. A capable provider should make its commitments clear and demonstrate that its product can support the organization’s actual requirements.

The decision deserves that complete comparison.

A sustainable identity platform should adapt with you

Fischer Identity has spent more than 20 years addressing complex IAM and IGA requirements. Our configuration-driven platform supports complex identity workflows, policies, and lifecycle processes without custom code, helping organizations adapt their business rules without maintaining a separate custom code base for each requirement.

That distinction matters over the life of an identity program. Organizations need flexibility as their operations evolve, along with a sustainable way to maintain the underlying platform.

Fischer is an experienced leader and a quiet underdog in this industry. Instead of spending millions trying to dominate the marketing conversation, we invest in the product, customer experience, and long-term success of the organizations we serve. That focus shapes our work.

AI creates valuable opportunities to improve software development. Organizations should explore them with a clear understanding of the commitments they are making.

Before replacing a SaaS identity platform, ask whether the projected savings still hold after accounting for years of business changes, maintenance, security, staffing, and operational support.

The organizations that moved away from homegrown enterprise systems learned those costs through experience. AI gives us a new way to build software. We should carry those lessons forward.