Taking Over an AI-Built Application: What We Check Before Adding Features

"Can You Just Add These Features?"

The request usually arrives in a friendly, practical form. A business owner built the first version of an application with an AI coding assistant. It runs. Customers or staff use it every day. Now the business has grown and the owner has a list: a new report, another user role, an integration with a payment provider, a mobile-friendly form. Can we add these?

The honest answer is yes, but not on the first day.

We recently took over an application like this. The client knew their business thoroughly, had no background in software development, and had built the whole thing through conversations with an AI assistant. What they handed over was source code, and only source code. For the client's privacy we do not describe the project or its field here.

In an earlier article we described how we recover knowledge from an undocumented codebase: reading the routes, the database, the roles, and the workflows back into documents a team can maintain. This article picks up where that one ends. Once we know what the application does, what do we check before we change it, and why does the owner's feature list wait until those checks are done?

Working Code Is Not Yet Owned Code

An application that works today has passed one test: it does what was asked, for the cases that were tried. That is a real achievement, and it is more than many first versions manage.

It is not the same as being ready to grow. Every new feature touches something that already exists: a table, a permission, a page, a background job. If nobody understands those parts, every change is a guess, and the cost of a wrong guess lands on the people who use the system.

This matters more with AI-built code for a simple reason. The assistant answered each prompt on its own terms. It did not keep a plan of the whole system, and it did not ask the questions an engineer would ask before writing anything: who is allowed to do this, what happens when the input is wrong, what if two people do it at once. The developer's side of this is covered on qadrlabs in AI Can Write Code. But Can You Read It?. Its point, put in an owner's terms, is that you only own software when someone can predict where it needs to change before changing it.

So the first phase of a takeover is not building. It is making the application understood, agreed, and safe enough to build on.

First, Agree on What the Application Is For

In an AI-built project the prompts were the specification, and the prompts are usually gone. Some of what the code does was a deliberate choice by the owner. Some of it is simply what the assistant produced, and the owner has been living with it. Before we look at the technical health of the code, we need to know which is which.

On this project that work had five parts:

• Reviewing the recovered documentation. The feature list, data diagram, role matrix, and workflows from the recovery phase were read through again, this time as a description of the business rather than of the code.
• Analysing the system as it runs today. How the application is actually used: which features people rely on, which they avoid, and which manual workarounds have grown up around it.
• Brainstorming directly with the client. Sitting with the owner and walking through the application screen by screen. "This page lets any staff member delete a record. Is that what you want?" is a question only the owner can answer.
• Requirement gathering. Turning the owner's list of new features into written requirements: who uses each one, what it must do, and what it must not do.
• Requirement analysis. Checking the new requirements against the existing system. Some fit cleanly. Some conflict with rules already in the code. Some depend on parts of the application that need repair first.

The output of this phase is agreement. The owner and the development team share one description of what the application is supposed to do, which is the thing an AI-built project most often lacks.

The Technical Checks

With the intended behaviour agreed, we examine whether the code can support it. These are the eight areas we checked on this project. For each one we describe what we look for, why it matters before new features, and a question an owner can ask any team that takes over their application.

Access and Secrets

We confirm that the code, server, database, domain, and third-party accounts are held by the owner's organisation, and we look for secrets in places they should not be: passwords, API keys, and tokens written directly into the code or committed to the repository.

AI assistants often place a key wherever it makes the example work. A key that has been in a repository, or shared in a chat, should be treated as known to others and replaced.

Why first: a new integration usually adds another key. Adding it to a system whose existing keys are exposed multiplies the problem.

Ask: "Which credentials did you find in the code, and have they been rotated?"

Server-Side Authorization

Most business applications serve several kinds of user. We check where the rule "who can do what" is enforced. The safe answer is on the server, before the action runs. A common weak answer is in the page only, where a button is hidden from some users while the action behind it still accepts anyone who reaches it.

Why first: new roles and new features are among the most common requests. If the existing permission model is unclear or enforced only on screen, every new role inherits that weakness.

Ask: "If a user types the address of a page they should not see, what stops them?"

Dependencies and Versions

We list the framework, its version, and every library the application uses, then check them against supported versions and published security advisories. We also look for packages that were installed for one attempt and never removed.

Why first: a new feature written on an outdated framework has to be rewritten when the framework is upgraded. It is cheaper to settle the foundation before adding to it.

Ask: "Is the framework version still receiving security fixes?"

Data Integrity

We read the database structure and compare it with how the data is used. Are relationships between tables enforced by the database, or only assumed by the code? Is input validated before it is saved? Are there duplicate or contradictory records that suggest a rule was enforced in one place and forgotten in another?

Why first: data outlives code. A bug can be fixed in an afternoon. Records that were saved wrongly for months may need careful repair, and new features built on them repeat the error.

Ask: "What would happen to our existing data if this feature were added tomorrow?"

Duplicated or Inconsistent Logic

This check is particular to AI-built applications. When a system is built through many separate prompts, the same business rule is often written several times, in slightly different ways. A discount, a deadline, or an approval condition may be calculated one way on a form and another way in a report.

We look for rules that appear in more than one place and confirm with the owner which version is correct.

Why first: changing a rule that lives in three places means finding all three. Missing one produces the kind of bug that users notice before developers do.

Ask: "If we change this rule, how many places in the code need to change?"

Automated Tests

We check whether the application has automated tests and what they cover. In AI-built projects the usual answer is that there are none, because nobody asked for them.

Why first: tests are how a team knows a change did not break something else. Without them, every new feature has to be verified by hand, and something will eventually be missed.

Ask: "How will we know that a new feature has not broken an old one?"

Error Handling and Logs

We look at what happens when something goes wrong. Does the user see a clear message, or a technical error page? Is debug mode switched off on the live server, so internal details are not shown to visitors? Are errors written to a log that someone can read?

Why first: new features bring new failures. If the application fails silently, problems are reported by customers instead of found by the team.

Ask: "When the application fails, where do we find out why?"

Deployment and Backup

We find out how code reaches the live server, whether there is a separate environment to test changes before users see them, and whether the database is backed up somewhere other than the server itself.

Why first: every feature has to be released. A release process that consists of copying files to the live server, with no tested way back, turns every release into a risk.

Ask: "If a release goes wrong, how do we return to the previous version?"

Stabilise First, Then Build

After the checks, the work splits into two lists: what needs repair, and what the owner wants to add. On this project we agreed with the client to work through the first list before starting the second.

That order can feel slow to an owner who came with a feature list. In practice it is what makes the feature list affordable. Each new feature lands on a system with a known permission model, a clean set of credentials, consistent rules, and a way to release safely. Building features first and repairing later means each repair has to work around the features added in the meantime.

Stabilising does not mean rewriting the application. The owner's first version represents real decisions about their business, and most of it is worth keeping. Stabilising means making the existing behaviour explicit, safe, and changeable, so that growth builds on what is already there instead of replacing it.

What This Means If You Built Your Application with AI

If you built your application with an AI assistant, you have done something useful: you proved the idea works and you have a system people use. Needing an engineering team to take it further is not a failure of the owner or of the tool. It is the analysis, design, and engineering work that a first version skips, done at the point where it starts to matter.

A few things make a takeover faster and cheaper:

• Gather access before the first meeting. The code repository or a copy from the server, hosting and server logins, the domain account, the database, and any third-party services.
• Write your feature list as problems, not solutions. "Staff spend an hour each week compiling this report" tells a team more than "add an export button".
• Bring real examples. A few typical cases, and one or two awkward ones, from the way the application is used today.
• Keep your prompts if you still have them. Old chat sessions are not documentation, but they can show what you asked for and why.

And when you talk to a team about taking it over, ask how they will check the application before they change it. A team that starts adding features on day one without asking those questions is guessing with your system.

Closing

An application built with AI is a legitimate starting point. Growing it safely takes the steps the first version skipped: agreeing on what it is for, checking whether the code can support that, and repairing what cannot before building on top of it.

If you have an application built with AI that now needs to grow, and you are not sure what state it is in, get in touch. Tell us what it does and what you want it to do next. We will start by understanding what you already have.