When is it time to build something yourself?

Many organizations buy large systems to solve relatively bounded problems. The systems are implemented, integrated and maintained — but after a few years, perhaps only a fraction of the functionality is actually used. The rest lives on as menus nobody opens, modules nobody dares to decommission, and capabilities that sounded important during procurement but never became part of the business.

That does not necessarily mean the system was the wrong choice. A standard product can provide stability, support, security updates and the accumulated experience of many other customers. But when AI-assisted development makes it faster and cheaper to create software, we need to ask the question again:

When is it better to build something small and purpose-built than to buy something large and general?

We tend to compare the wrong things

When organizations choose between buying and building, they usually compare the license cost with an estimated development cost. That comparison is far too simple.

A purchased system carries costs for procurement and implementation, configuration, integrations, training, licenses, vendor management, upgrades, adapting the organization's processes — and for functionality that is never used.

A system built in-house carries different costs: analysis and development, testing, documentation, operations and monitoring, security updates, staffing and skills, incident management and long-term maintenance.

So the real question is not which option is cheapest to acquire. It is:

Which option is the organization best equipped to take responsibility for across the system's entire lifetime?

AI changes the cost of starting to build

AI-assisted development has already lowered the threshold for creating prototypes and smaller systems. An experienced developer can more quickly explore alternative solutions, create user interfaces, write integrations, generate tests, document code, refactor existing implementations and try an idea with real users.

This means organizations do not always have to make one big buy-or-build decision up front. Instead, they can build a small, bounded solution to understand the problem better. A working prototype can show which needs are real, which integrations are required and which parts actually deliver value to users.

That matters, because a requirements specification usually describes what people believe they need. A usable prototype shows what they actually use.

But faster code is not the same as a maintainable system

This is where the discussion often becomes too optimistic.

AI can help us produce code faster. It does not automatically take responsibility for the architecture, information security, availability, personal data processing, operational reliability, dependencies, future upgrades or business continuity.

It is relatively easy to get an AI assistant to build something that works during a demonstration. It is considerably harder to build something that can still be understood, changed and deployed safely five years later.

The difference between a prototype and a business system is not primarily more features. It is responsibility.

When can we trust AI-developed code?

The question actually contains a misunderstanding. We should not trust code because it was written by a human. Nor should we distrust code merely because it was generated with AI.

We should trust the processes that make the code verifiable. Code does not become reliable through its origin, but because we can show that it:

• meets documented requirements
• has relevant automated tests
• has been reviewed
• handles errors in a predictable way
• contains no known critical vulnerabilities
• can be monitored in operation
• can be restored
• has documented dependencies
• can be changed without unreasonable risk

An experienced developer can write bad code. An AI can generate good code. The reverse is also true. The decisive difference is whether the organization has the ability to judge the result.

AI reduces the time it takes to produce code. It does not automatically reduce the need for technical judgment. In some situations it increases it, because larger amounts of code can be produced in less time.

When are we ready to maintain AI-developed systems?

An organization is not ready simply because it can build the system. It is ready when it can answer the following questions:

• Who owns the system?
• Who understands the architecture?
• Where is the source code?
• How are changes reviewed?
• How are new versions tested?
• How are incidents detected?
• How are security updates handled?
• Which external libraries and AI services does the system depend on?
• How is the system restored after a failure?
• What happens when the original developer leaves?
• How is the system decommissioned when it is no longer needed?

If the answers are missing, the organization does not have a maintained system. It has a working prototype with a growing dependency. That is true regardless of whether the code was written by employees, consultants or AI.

Not all systems are equally suitable to start with

There is no general point in time at which AI-developed code suddenly becomes safe for every type of system. The risks differ.

An internal tool that compiles information and always lets a human check the result can be a good candidate. A system that makes decisions about citizens, handles sensitive personal data or controls critical infrastructure is something else entirely.

Good early candidates typically have a clearly bounded function, a limited number of users, low consequences on failure, little sensitive information, clear human oversight, a manual fallback routine, few critical integrations and measurable benefit.

Bad first candidates are systems where a failure can affect people's rights, halt a core operation or create hard-to-detect security problems.

Do not start with the core system

Organizations that want to explore building in-house should not start by replacing their largest business system. Start at the edge. That might be an internal workflow, a data quality tool, a bounded integration, a search or reporting service, a decision-support tool where the human makes the decision, an administrative interface — or a manual process that today runs on spreadsheets and email.

Build something small. Let real users try it. Measure whether it saves time or improves quality. Document how the solution was built and what it takes to maintain it.

Then the organization is not just evaluating AI's ability to write code. It is evaluating its own ability to own the result.

Building in-house does not mean building everything

The choice is not binary. An organization can combine standard products, open components, cloud services, its own integrations, smaller purpose-built applications and AI-assisted development.

The most sensible approach may be to buy what is generic and build what is business-specific. Identity, logging, databases and standardized document management rarely need to be reinvented. But the part that expresses the organization's unique way of working may not need to be forced into a large product designed for hundreds of other use cases.

The limit is organizational, not chronological

It is tempting to ask when AI will be good enough for us to trust AI-developed systems. Maybe in two years. Maybe in five.

But the most important limit is not on the calendar. It runs between organizations that can verify, own and maintain software and organizations that can only order it.

AI can already be useful for developing bounded solutions. But an organization that lacks a test strategy, architectural competence, security practices and clear system ownership does not become ready just because the models improve. On the contrary, it can become more dangerous as it gets even easier to create systems that look finished.

The new question before the platform

We used to ask:

Which system should we buy?

Now we first need to ask:

Which part of the problem is generic, which part is unique to us, and what are we prepared to maintain ourselves?

Sometimes the conclusion is to buy an established product. Sometimes it is to build a small solution of your own. Often the answer is a combination.

What matters is that the decision does not start with the platform — nor with fascination over what AI can generate. It starts with the business, the risk and the responsibility.

It is not time to build yourself when AI can produce the code. It is time when the organization can take responsibility for the system the code becomes part of.