AI can build your app in days. What will it cost to maintain?

Today, you can create a working application demo in a matter of hours. Sometimes half a day is enough. With AI, building an operational platform or an internal tool can take days. AI has accelerated development. It’s a fact. I see it firsthand in our projects. Obviously, it’s not only about speeding up engineers' work. People without technical skills create tools and apps for personal or work use, so building a product no longer seems like a challenge.

For the record, it's fantastic that we can now produce a clickable demo, a working prototype, or even a production application in a short time. You can even charge customers for using it. People are genuinely building startups this way.

But the challenges come afterwards: when you need to maintain the application, make changes, and hand it over to someone else when people no longer want to work on it themselves. And that’s a huge gap.

Why AI-generated applications can become difficult to maintain

AI can generate an enormous amount of code in a very short time. The question is what happens to a business in 10 years. Or even in 2 years. Will the software still be secure and reliable? Could a vulnerability lead to a data breach? Could someone quickly build a competing solution at half the price? Or what happens when business requirements, the database structure, or user behaviour change?

It’s hard to answer those questions at the start. Strategies might evolve within a year, and so can business needs. Innovations in the AI space are evolving faster than leaders can reliably operationalise them.

That’s why maintenance is so important. Will the product become difficult to maintain over time? How do you debug such a system? How well will AI cope with modifying the code it previously generated?

While developers know how to maintain AI-assisted code, long-term maintenance of applications built predominantly by AI is a completely different challenge. But from what I am seeing, without a human overview - and by that I mean a senior engineer who knows what questions to ask or how to challenge the suggested solutions - it’s quite easy to build an application that’s hard to understand and which, in turn, can become hard to fix or scale with time. Perhaps maintaining these applications will prove just as straightforward as creating them. But teams might also discover entirely new problems.

Why would you regenerate an application?

Some may say that generating a new version with updated requirements might be simpler than understanding and gradually modifying the existing code. And this way of thinking existed long before AI. Developers have always been tempted to join an existing project and say, "Who wrote this for you? I'll rewrite the whole thing."

Creating something from scratch might seem easier than understanding someone else's code. The biggest problem is underestimating the work involved. An application might have fairly standard features: registration, login, password resets, user management, and email notifications. Rebuilding something like that might seem like a few days' job. Then, a few weeks later, the engineers still don't understand why the new application doesn't behave like the old one or why they can't reproduce all its functionality.

Reverse engineering an existing platform is one of the easiest areas to undervalue. That applies to developers joining a project and to anyone else examining a system for the first time. There are plenty of things you simply can't see until you investigate the platform in detail. That's why I would be cautious about quickly rewriting existing applications with AI.

Why technical expertise still matters in AI-assisted development

Recently, I tried a little experiment. It was partly for fun, but I also genuinely needed the application. I wanted to organise my personal documents. I didn't particularly want to keep everything in Dropbox or rely entirely on file search. A straightforward Mac application that would help me organise it all would be enough. I described my requirements to Claude and asked it to consider the problem and suggest a solution.

It replied, "Great, let's build it in Node.js." I asked, "Why Node.js? What other options do we have?" and also suggested Swift because I wanted a native macOS application. Claude explained that it might make more sense to use Node.js with Electron. That would mean building the application in JavaScript and packaging it as a desktop application for Mac, with an experience similar to using a native app.

In the end, I agreed to that approach. But I was able to have that conversation because I had the technical knowledge to challenge the initial recommendation and knew what questions to ask. Without that background, I probably would have accepted the first suggestion.

It's a bit like someone putting me on a plane and saying, "Here's AI. It'll help you navigate it." I wouldn't take that risk. I'd much rather have someone who has flown hundreds of hours and knows how to fly. I wouldn't want to rely entirely on a model whose mistakes I might not recognise. Of course, building an application isn't quite the same. But the underlying point is similar: You need enough knowledge to judge whether the answers you're getting make sense.

While developing my application, Claude suggested storing certain information in a database. I pointed out that it wasn't necessary because a configuration file would do the job. It responded with something along the lines of, "You're right. It's a good thing you spotted that." Now, would storing that information in a database have prevented the application from working? No. It probably would have worked perfectly well.

The issue is that future changes might have become more difficult or expensive. What looks like a minor technical decision can have consequences that aren't visible when you first get the application running.

Building with AI is fast. Maintaining the result requires a plan

Before relying on AI-generated software, verify whether it can be easily maintained, scaled, or updated. That means having an experienced developer review the architecture and code, checking whether critical functionality is properly tested, and making sure someone unfamiliar with the project can understand and modify it without rebuilding everything from scratch.

Having access to a tool doesn't necessarily mean individuals know how to use it properly. The model might recommend a technology that gets you to an initial result quickly, but it might not be the most suitable choice for the product. Without technical knowledge, you might not even know what questions to ask.

Even though there are countless opportunities for AI and for building a platform with it, leaders need to consider the potential trade-offs and the final cost. Maybe it won’t be a financial cost at first. But it may accumulate into a system that no one knows how to operate without breaking something else.